In 1494, a Franciscan friar named Luca Pacioli published the first printed description of double-entry bookkeeping. The mechanics have changed beyond recognition since then. The principle has not.
An entry is not a story because someone wrote it down. It becomes meaningful because it has a corresponding entry: a record that can be checked against the thing that actually happened.
Five centuries later, many finance teams still live with a strange break in that logic.
Someone approves a payment. Someone enters it into a portal. A confirmation number appears. The screen says sent.
Then the real work begins.
Did the rate execute? Did the payment leave? Did it arrive in the account that matters? Was it accepted by the local rail? And when it is finally complete, can the team explain the transaction to its ledger without opening six tabs and asking three people for screenshots?
Sent is not the end of a payment. It is the beginning of an obligation to know what happened next.
The missing half of the transaction.
The easiest part of cross-border money movement is the moment a person sees a button and presses it. That button hides a longer chain: account validation, controls, available funds, quote validity, conversion, routing, local delivery, screening, confirmations, exceptions and recording.
In older systems, the information about those stages often lives in different places. A bank portal has one version. A payment provider has another. The ERP may have a third. Someone’s inbox has the detail that makes the first two intelligible.
This is how a finance team becomes an integration layer for its own money.
Seven moments in a complete payment.
- An instruction is made: amount, beneficiary, purpose and timing become explicit.
- The business gives it authority: approval and evidence attach to the decision.
- A real price is obtained: the team knows what it can actually execute and under what conditions.
- The instruction executes: the question changes from should we do this to what is happening now?
- The local result is delivered: payroll, supplier or operating account receives a usable outcome.
- The status becomes knowable: the team can distinguish initiation from a completed result.
- The record returns to the books: purpose, evidence, approval and status travel back to the accounting record.
Why reconciliation is not an afterthought.
Reconciliation is often described as back-office work, as though it begins after the important thing has happened. It is the opposite.
Reconciliation is the business proving to itself that the instruction, the outcome and the accounting record agree. It is where a company discovers whether a promised payment became a real one.
This is why the right question is not, can we automate the payment? It is: can we automate the complete, accountable payment?
Good automation removes rote coordination and makes the remaining decision more legible. Finance teams should spend their attention on whether capital ought to move, how much risk the business will accept and what the next decision should be—not on reassembling the basic facts of a payment that has already happened.
Pacioli’s insight still holds. The record must meet reality.
Questions worth asking.
What does final mean in a payment?
The answer depends on the rail, rules and legal framework. Operationally, a team needs a clear definition of when an instruction is irreversible and when the intended recipient has a usable result.
Does an ERP integration solve reconciliation by itself?
No. An integration is valuable when it returns a coherent transaction record. It cannot invent missing purpose, approval, status or evidence after the fact.
Historical reference: Library of Congress — History of accounting
Settlement reference: BIS — Risks and efficiency in retail payment systems