The chain
Every payment has a chain behind it, and most reconciliation pain comes from the chain being broken in the middle rather than at either end.
| Link | The question |
|---|---|
| Bank transaction | What actually moved through the account? |
| Payment | Which payment instruction does that correspond to? |
| Obligation | What was that payment settling — which invoice, bill or agreement? |
| Ledger entry | How was that recorded in the books? |
Match ties the four together. Where a link is missing or ambiguous it says so, rather than picking the most plausible option and moving on.
Why start with something that moves no money
Three reasons, and they compound. It carries no money-transmission exposure, so it needs no processor relationship and no licensing conversation before it can exist. It exercises the whole canonical model and the connector contract end to end, so the parts that would be hardest to change later get used first. And if the model turns out to be wrong, that surfaces in weeks — while being wrong is still a refactor rather than a migration of live payment data.
Building the money movement first and reconciliation afterwards is the more obvious sequence and the more expensive one. By the time reconciliation exposes a modelling error, there is production payment data shaped by that error.
The canonical model
Pey's internal types are deliberately not shaped like any one accounting system's schema. A model that mirrors one ERP works beautifully against that ERP and needs rewriting for the second one — which defeats the entire premise of a payment graph fed by many ledgers.
- Money is always an amount and a currency together.
- Every record carries a tenant, required, with no default.
- An obligation is a general concept, not "an invoice" — because what a payment settles is not always an invoice.
- Events are emitted for the connected system to book; nothing is posted by Pey.
What this does not do
Match reconciles. Collect and Pay are later capabilities.
In build.
See Connectors.
Choosing the cheapest rail needs data worth deciding over, which Match produces.
Questions
Does Match need a processor relationship?
No. That is much of the reason it is first.
Can Match work against our existing bank feed?
It reads from a connected ledger. See Connectors.
When will it be available?
In build. Ask before planning around a date.
Related
How Pey reads a ledger, the first connector, and why the connector contract matters more than the first system it connects to.
ReconciliationMatching bank transactions to invoices, bills and journal entries in erp.io — the suggestion queue, confidence thresholds, and why you should never lower one to clear a backlog.