Paying suppliers usually involves two disconnected acts: recording the payment in the ledger, and separately telling the bank to move the money. Most of the risk in payables lives in the gap between them.
The manual pattern and where it breaks
The familiar routine is to select invoices for payment, post the payment entries, then build a file or key the payments into the banking portal by hand. Two lists of the same payments now exist, maintained by hand, and they can disagree — a supplier paid twice, an amount transposed, a payment recorded but never sent.
Booking and file generation as one action
The alternative is to treat payment selection as the single source. You choose the invoices to settle; the system posts the payment entries and produces the bank file from that same selection. There is no second list, so there is nothing to reconcile between them.
What this changes in practice
- Totals always agree. The file total is the posted total, because both derive from the same set of records.
- Bank details come from the supplier master. No re-keying of account numbers at the moment of payment, which is where fraud and typos concentrate.
- The audit trail is continuous. Invoice, approval, payment entry and bank file are linked rather than assembled afterwards.
- Partial payments stay honest. Settling part of an invoice updates the open item correctly instead of relying on a memo.
What still needs a human
Automation here removes transcription, not authority. Someone must still approve the payment run, and dual authorisation at the bank remains a sensible control. The point is that the person approving is looking at the same figures that will actually leave the account.
Before you switch
Confirm your bank’s file format and test with a small run. Clean the supplier master first — bank details, currency, payment terms. A payment file is only as good as the data it is built from.
