The payment succeeded. Now the hard part begins.
Ask any engineer what the difficult problem in payments is and they will describe authorisation — the routing, the latency, the success rate. It is a good answer, and it is the wrong one.
Authorisation is a question with a yes or no answer, delivered in under a second. Reconciliation is a question with no fixed answer at all, arriving in fragments over several days, from counterparties who each believe something slightly different, in currencies that do not agree, about money that has already moved.
Authorisation is where payments are exciting. Reconciliation is where payments are hard.
It is also where the merchant's pain actually lives. Nobody's finance team stays late because an authorisation took 400 milliseconds. They stay late because a settlement landed in the bank account and nobody can explain, to the rupee, what it was made of.
Why a cross-border payment is not an event
The single most damaging assumption in payments engineering is that a transaction is a thing that happens. It is not. It is a lifecycle, and it is stubbornly asynchronous.
A card is authorised. Later — sometimes seconds later, sometimes days — it is captured. The acquirer batches it. The network settles it. A bank credits an amount that is not the amount you authorised, because fees were deducted somewhere you cannot see. A currency conversion happened at a rate nobody told you at the time. Then, a week on, a refund arrives. Or a chargeback. Or a settlement adjustment nobody warned you about.
Which means the uncomfortable truth at the centre of this problem:
A terminal state is not terminal. A payment you marked as complete on Monday can change on Thursday, and your system has to be able to survive that without lying to anyone.
Any architecture that models a payment as a row in a table, updated in place, will eventually destroy its own history and be unable to explain itself. And in a regulated cross-border business, being unable to explain yourself is not an inconvenience. It is a compliance failure.
An amount is not a number
The second assumption that has to die is that money can be stored as a number.
A buyer in London pays £100. That is not 100. It is one hundred, in pounds, at a moment in time. Somewhere downstream it will become dollars, or it will become rupees, at a rate that existed on a particular day at a particular second, minus a markup, minus a fee, and the merchant will eventually see a figure in their Indian bank account that bears no obvious relationship to £100 at all.
If your ledger stores that as a number, the information required to explain it is already gone. So in our system money is never a bare quantity. It is an amount, a currency, and — where a conversion occurred — the rate that was applied, the timestamp it was applied at, and the reason it was applied. You do not add pounds to rupees. You do not average across currencies. You do not convert twice and hope.
This sounds pedantic. It is the difference between a merchant asking "where did my money go?" and getting an answer, and a merchant asking that and getting a shrug.
Everyone has a different version of the truth
Cross-border payments have an unusual number of participants, and they do not agree with one another.
We connect to many issuers and acquirers, across different networks, in different countries, speaking different protocols with different message formats, different batching behaviour, different settlement calendars and different opinions about what a transaction identifier is. One counterparty reports gross; another reports net of fees. One settles daily; another settles on its own rhythm and its own bank holidays. One tells you the FX rate it used; another simply hands you a number and lets you work it out.
So reconciliation is not really a matching problem. It is a translation problem, followed by a matching problem.
Before anything can be reconciled, every counterparty's version of events has to be normalised into a single internal representation of what happened — one vocabulary, one identifier scheme, one notion of time, one representation of money. That normalisation layer is unglamorous, enormous, and it is where most of the real engineering sits.
The architecture
1. Append, never overwrite
Our ledger is an immutable, append-only event log. Nothing that has been written is ever edited. A payment's life is a sequence of facts — authorised, captured, converted, settled, credited, refunded — each recorded as it becomes known, each stamped with when we learned it and who told us.
The current state of a transaction is therefore not stored. It is derived, by replaying its events. This costs a little more compute and buys something that cannot be bought any other way: at any point in the future, for any transaction, we can answer not only what its status is, but what its status was believed to be at any earlier moment, and exactly which piece of information changed it. That is the property an auditor asks for, and it is the property a merchant's finance team desperately needs and almost never has.
authorised(GBP 100.00) → captured(GBP 100.00) → converted(GBP→INR @ rate, t)
→ settled(net of fees) → credited(INR, to merchant account) ... → refunded(partial)
2. Double entry, because money does not appear
Every movement is recorded twice — as a debit and a credit — and the books must balance at every instant. This is not an accounting nicety imported into engineering. It is the strongest invariant available to a payments system, because it makes an entire class of bug impossible to hide.
Money cannot be created by a race condition. It cannot be quietly lost by a failed retry. If the two sides do not balance, the system knows immediately, rather than a merchant discovering it a month later.
3. Idempotency and deduplication, everywhere
Counterparties resend. Files get delivered twice. Webhooks fire again. A reconciliation system that processes the same settlement report twice will cheerfully double-count a merchant's revenue, and it will do so silently.
So every inbound fact carries a deterministic identity, and applying it twice has exactly the same effect as applying it once. This is the same discipline we apply to payment retries, for the same reason: in a distributed system, at-least-once delivery is the only kind you are actually offered.
4. Multi-way matching — and the exceptions are the job
Reconciliation compares what we believe happened against what each counterparty says happened, and against what the bank account actually shows. Three sources, three vocabularies, three clocks.
The great majority matches automatically, and that part is easy to be proud of and not very interesting. The engineering that matters is in the small fraction that does not: the transaction that settled in a different window, the amount short by a fee nobody documented, the conversion applied at a rate we did not expect, the entry that appears on one side and simply does not exist on the other.
Any system can reconcile the transactions that reconcile themselves. The whole value is in what you do with the ones that don't.
Exceptions are routed into a queue, classified by cause rather than by symptom, and — where the cause is understood — resolved automatically. What is left for a human is the genuinely novel, which is a very short list. The alternative, which is the industry norm, is a finance team with a spreadsheet and a long evening.
For an Indian exporter, the exchange rate is not a technical parameter. It is a large fraction of what they actually earn.
A payment collected in dollars has to become rupees, and precisely when that happens — and at what rate — determines what the merchant is paid. A rate is not a constant; it moves all day. Booking a conversion at a poor moment, or converting in small fragments each time rather than in a considered position, quietly costs the merchant money that no invoice will ever show them.
So FX is treated as a first-class part of the settlement architecture rather than an afterthought bolted to the end of it. Rates are captured, booked and recorded against the specific entries they apply to, so that every rupee credited can be traced back to the rate that produced it. And because we run both directions of a merchant's flows on one authorised stack, currency can be netted across them rather than round-tripped: a business earning dollars and paying dollars should not be converting into rupees and back again, paying a markup in each direction, for the privilege of using two different providers.
Every conversion you do not have to make is a markup the merchant does not have to pay. Netting is not a discount. It is arithmetic that a single-direction provider is structurally unable to offer.
Why two-way flows change the problem
This is the part that is genuinely different about our position, and it is worth being direct about it.
A provider licensed only for inbound collections can reconcile inbound collections. That is a real problem and they can solve it well. But they cannot give a merchant a single reconciled view of their international business, because half of that business — the vendor payments, the contractor payouts, the overseas subscriptions — is not on their rails and never will be. Two systems, two ledgers, two truths, and a human being in the middle with a spreadsheet trying to make them agree.
Our RBI PA-CB-I&O authorisation permits both directions on one regulated stack. That is usually described as a licensing advantage. It is more accurately an architectural one: it is what makes a single, consistent, double-entry ledger across a merchant's entire cross-border position possible at all. You cannot net currency across flows you cannot see. You cannot reconcile a business you only half observe.
Compliance stops being a project
An interesting thing happens once the ledger is correct: the compliance artefacts stop being work.
Foreign inward remittance documentation, purpose codes, audit trails, settlement reports — these are not separate deliverables to be assembled by hand at the end of a quarter. They are views over data the ledger already holds, because it was recorded properly the first time. Generating them is a query, not a project.
This is the quiet reason the finance team is the biggest beneficiary of engineering they will never see. They stop being a reconciliation department, and go back to being a finance function.
What this returns to the merchant
Reconciliation engineering is invisible, and it is worth more to a merchant than almost anything else we build.
It returns days — the days a finance team currently spends matching export collections against international payouts that live in different systems. It returns money, in the FX markup that netting removes and the settlement discrepancies that would otherwise have been written off as too small to chase. And it returns something harder to price: the ability of a business to actually know its own cash position across borders, in a single currency, in one place, without asking anyone to take it on trust.
A merchant should never have to prove to us what they were paid. They should be able to ask, and be told, to the rupee, with the rate and the reason attached.
That is the whole ambition. The ledger is not a back-office system. It is the product.
Frequently asked questions
What is payment reconciliation?
Payment reconciliation is the process of matching what a business believes it was paid against what its payment provider, its acquirers and its bank each report, and resolving the differences. In cross-border payments it is significantly harder than in domestic payments, because amounts arrive in different currencies, fees are deducted at multiple points, settlement happens on different calendars, and each counterparty describes the same transaction differently.
Why is cross-border payment reconciliation so difficult?
Because a cross-border transaction is not a single event. It is an asynchronous lifecycle — authorised, captured, converted, settled, credited, and sometimes refunded or charged back days later — involving multiple issuers, acquirers, networks and banks, each using different protocols, identifiers, settlement calendars and fee structures. The amount that lands in the merchant's account is rarely the amount the buyer paid, because currency conversion and fees have intervened.
Can a payment's status change after it is completed?
Yes, and any system that assumes otherwise will eventually mislead its users. Refunds, chargebacks and settlement adjustments can arrive days after a transaction was considered final. A correctly built ledger records these as new, appended facts rather than by editing history, so that the transaction can always be explained as it was understood at any point in time.
Why should a payment ledger use double-entry accounting?
Because double entry makes an entire class of error impossible to hide. Every movement is recorded as both a debit and a credit, and the books must balance at all times. Money cannot be created by a race condition or quietly lost by a failed retry — if the two sides disagree, the system knows immediately, rather than a merchant discovering the discrepancy weeks later.
How does the exchange rate affect what a merchant is actually paid?
Substantially. A payment collected in a foreign currency must be converted to rupees, and the rate moves throughout the day, so the timing and manner of that conversion directly determines the merchant's settlement amount. Converting in fragmented amounts at arbitrary moments, or converting twice because inbound and outbound flows sit with different providers, costs the merchant money that never appears on any invoice.
What is currency netting in cross-border payments?
Netting means offsetting a business's incoming and outgoing flows in the same currency instead of converting each one separately. A company earning US dollars and also paying US dollar suppliers does not need to convert dollars into rupees and back again, paying a markup in each direction. Netting is only possible when both directions run on a single platform, which is why it requires a provider authorised for both inbound and outbound flows.
How can reconciliation be automated?
By normalising every counterparty's reports into one internal representation of money, time and identity, then matching them against an immutable, double-entry ledger. The transactions that match are settled automatically. The value lies in the exceptions — entries that are short by an undocumented fee, settled in an unexpected window, or converted at an unanticipated rate — which are classified by cause and, where the cause is understood, resolved without human involvement.
Ready to know exactly what you were paid?
PayGlocal runs inbound collections and outbound payouts on one RBI-authorised stack across 180+ countries — which means one ledger, one reconciled view, and one answer to the question of where your money went.
Talk to our team, or read the APIs at
docs.payglocal.in
Mohit Agrawal is Sr. Director, Engineering at PayGlocal. An IIT (BHU) graduate and former AWS engineer, he specializes in distributed systems, AI-powered risk engines, and payment infrastructure, helping build secure, scalable solutions for global commerce.
