EHORS WinXEHORS WinX
Explore
← ehors-tech.comRequest a demo

Insights

AP in real time: know what you owe before the statement arrives

Ask a hotel controller what the property owes suppliers right now and the honest answer is usually "give me until Thursday". The money was owed the moment the goods crossed the loading dock — but the record waits for data entry, and the truth waits for the supplier statement. Here is why payables lag reality, and why the fix is the database, not the workload.

The pain: the payable exists before the record does

What-we-owe is always stale. Goods are received all week; invoices are keyed when the finance office gets to them. Between those two events the AP balance management sees is wrong — sometimes by a delivery, sometimes by a month of them. The supplier statement arrives and becomes the property's de facto ledger, which is exactly backwards.

Invoices arrive orphaned. A supplier bills for goods someone received weeks ago. Which order was that? Was the quantity right? Was the price the contracted one? When the purchase order and the receipt live in another system — or a lever-arch file — checking is an investigation, so it gets skipped, and overbilling and duplicates slip through.

Payment day is a scramble. What is due this week, to whom, and what can wait? Built from paper, the payment run takes a day and still misses things — a supplier put on stop-credit over an invoice that was actually paid, or paid twice because the duplicate wore a different reference.

RECORDED AT DATA ENTRY RECORDED AT RECEIPT goods received invoice keyed weeks of invisible debt ✕ truth arrives with the statement goods received payable exists now invoice matches the receipt ✓ what-we-owe is live all month

Why it happens: purchasing and payables in different systems

This is the AP half of a familiar structural problem. The events that create and justify a payable — the order, the receipt, the price agreed with the supplier — happen in the purchasing system. The liability, the approval and the payment live in the accounting system. Connect them with exports and re-keying, and every handover adds delay and drops context:

A generic ERP handles this well inside itself — but in a hotel, the purchasing side is tangled with recipes, outlets, stores and folios it cannot see, so properties run purchasing in one place and payables in another, and the gap is bridged by the month-end close. The multi-system tax, again.

FROM LOADING DOCK TO PAYMENT — ONE LINKED CHAIN Goods received payable exists — now Supplier invoice recorded against PO + receipt Payment batch due items · approval to release Paid cheque · transfer · online supplier ledger + GL, once Because the chain is one record, these are queries — not month-end projects: · What do we owe, right now, by supplier and by age? · What cash do payments need next week — and which invoices earn a discount if paid early? · Which received orders have no invoice yet — the debt no one has billed us for? Same database as purchasing and the outlets — see the purchasing article for the upstream half of this chain.

How WinX fixes it: AP on the purchasing database

WinX accounts payable is a module on the same database as purchasing, stock and the general ledger — the ERP is not attached to operations, it is operations:

The shift: from AP as a reconstruction of what operations did last month, to AP as the financial shadow operations cast in real time. The supplier statement stops being news.

Proven where the invoice volume is heaviest

Payables pressure scales with outlets and suppliers. Manila Ocean Park + Hotel H2O runs around 40 outlets on one WinX installation — every one of them receiving goods, consuming stock and generating supplier obligations on the same records the finance office pays from. Multi-property groups like The Signature Suites (Kuala Lumpur + Puchong) get the same chain per property with consolidated group reporting — payables visible per entity and in total, from one login.

Common questions

Why is accounts payable always a surprise in hotels?
Because the obligation and the record are born in different systems at different times. The property owes the money when goods are received; the finance system learns when someone keys the invoice. Between those moments the AP number is wrong, and the supplier statement delivers the correction.
How does one database change invoice checking?
The supplier invoice records against the purchase order and goods receipt that justify it — the same linked records the storekeeper created. Mismatches surface at entry, when they are a conversation; not at audit, when they are a write-off.
How are supplier payments controlled?
Approved invoices flow into payment batches by supplier and due date, under payment authorisation controls governing who approves and releases. The payment posts to the supplier ledger and the GL in the same motion — cheque, bank transfer or online.
What does real-time AP do for cash flow?
Every payable carries its due date from the moment it exists, so cash required next week is a query on live data, not a projection from last month's close. Ageing is a report; statement reconciliation stops producing surprises.

See your payables live — received, invoiced, due and paid on one chain.

Request a WinX demo