Payment reconciliation software earns its keep on the exceptions, not the matches. The happy path — a payment arrives, the settlement file agrees, the ledger balances — is the easy 95%. What costs a finance team its week is the remainder: the partial capture, the refund that crossed a settlement boundary, the chargeback that arrived against a payout already made, the gateway that reported success and then quietly reversed.
Most systems are built for the 95% and leave the rest to a spreadsheet and a person who knows. That person becomes the reconciliation process. When they are on leave, month-end slips; when they resign, nobody can explain last quarter.
The work here is the other 5%: a ledger with entries that cannot be silently overwritten, matching that survives multi-currency and partial settlement, and an exceptions queue with enough context attached that whoever opens it can decide rather than investigate. Every automated match keeps its evidence, so an auditor asking why a line cleared gets an answer from the system rather than from memory.
This is the line where the record is first-hand. Anupam ran payment infrastructure in MAS-regulated environments — cross-border collection accounts, SWIFT payouts, and the reconciliation discipline underneath them. That is a track record, not a certification the firm holds.
Scope
Append-only entries with the source event attached, so a balance can always be explained by the transactions that produced it. Corrections are new entries, never edits — which is what makes a historical figure reproducible six months later when somebody asks how it was arrived at.
Multi-currency, partial settlement, fees deducted at the processor, payouts batched across days. The matcher is written against the settlement files your providers actually send rather than the schema in their documentation, because those differ more often than anyone expects.
Every unmatched item arrives with the candidate matches, the amounts, the timing gap and the reason it failed — enough to decide in one screen. The measure of this queue is not how small it is; it is how rarely somebody has to open a second tab to resolve an item.
Routing across providers, retry logic that understands which failures are worth retrying, and failover that does not double-charge. Orchestration only earns its complexity above a certain volume or a second provider — below that it is a layer to maintain for no gain, and we will say so.
Idempotency keys on anything that moves money, webhook replay handled rather than assumed, and an audit trail written for somebody hostile reading it a year later. Anything irreversible keeps a human gate, and that gate does not come out because it slows the flow.
It answers one question repeatedly and defensibly: does what we believe we received match what the processor says it settled. Payment reconciliation software ingests settlement files and internal transaction records, matches them, and surfaces what did not match with enough context to resolve. The part worth paying for is the second half — anyone can match the items that agree.
Payment orchestration is a routing layer across multiple providers: choosing where a transaction goes, retrying intelligently when one fails, and failing over without double-charging. You need it when you genuinely have more than one provider, or volume high enough that a percentage point of authorisation rate is real money. Below that it is a layer to maintain for no gain, and adding it early usually means debugging your own abstraction instead of your payments.
Usually, and that is the normal shape of the work. Most engagements sit between systems that already exist — a processor, an accounting package, a bank feed, and an internal database that half-tracks the same events. The valuable software is the layer that reconciles them, not a replacement for any of them. Where a provider's API cannot support what is needed we say so early, because discovering it halfway through is the expensive way to learn it.
As first-class events rather than corrections. A refund issued after its original payment has settled, or a chargeback landing against a payout already made, is the case that breaks naive reconciliation — the arithmetic balances only if the ledger can represent an entry that reverses across a period boundary. That is a design decision made at the start; retrofitting it later usually means rebuilding the ledger.
The firm holds no certification, and you should treat any small firm claiming otherwise with suspicion. What is true is narrower and checkable: Anupam has operated payment infrastructure inside SOC 2 and ISO 27001 environments and worked to those controls. If your procurement needs a certified vendor, that is a real constraint and the honest answer is that it rules us out — you will hear that on the first call rather than in a security review.
There is no rate card, because the price follows the scope and the scope follows what your settlement files actually look like. The first session is a read of the real data — reconciliation work is quoted badly when it is quoted from a description, because the exceptions nobody mentioned are most of the effort. Once scope is written it is a fixed fee against that document, billed at milestones.
In one place, usefully: ranking candidate matches on the exceptions queue so a person decides faster. That is classification against a reviewable suggestion, with a human approving before anything posts. Where it does not belong is anywhere a model's output would move money without review — the failure mode of a confident wrong match on a ledger is a corrected balance nobody notices for a quarter.
Founder · he answers these himself
Fixed fee, scoped in writing before anything starts. No hourly billing, no verbal scope.
Related: Fintech app development · Custom software development · AI workflow automation · About Anupam Shah · How we work