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.
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:
- The receipt that should create the liability instead waits for an invoice to be keyed.
- The invoice that should be checked in seconds against its order becomes a filing hunt.
- The payment that should close a linked chain instead references a supplier and an amount, and hopes.
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.
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 receipt creates visibility — goods received against a purchase order are immediately part of the payables picture, before any invoice is keyed. Received-not-invoiced is a standing list, not a year-end audit finding.
- Invoices check themselves against their chain — the supplier invoice records against the order and receipt that justify it; quantity and price mismatches surface at entry, and duplicates have nowhere to hide.
- Payment runs with control — approved invoices gather into payment batches by due date and supplier, released under payment authorisation profiles; the payment posts to the supplier ledger and the GL in one motion, whether cheque, transfer or online.
- Cash needs, ahead of time — every payable carries its due date from birth, so next week's cash requirement is a query on live data. The same live-ledger logic that puts P&L on the day.
- One vendor, one truth — the AR side works the same way (outdated AR is the mirror-image problem), so both sides of the cash cycle read from the same live ledger.
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