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.
Anupam Shah ran payment infrastructure in MAS-regulated environments — cross-border collection accounts, SWIFT payouts, and the reconciliation discipline underneath them.
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 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.
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.
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. Anupam Shah has operated payment infrastructure inside SOC 2 and ISO 27001 environments and worked to those controls.
Price follows scope, and scope follows what your settlement files actually look like, so the first session is a read of the real data. Reconciliation quoted from a description is quoted badly: the exceptions nobody mentioned are most of the effort.
The fee is fixed against that scope and 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.
You do, outright. IP assignment is signed before repository access, by everyone who touches the code, and it covers AI-assisted output. Handover includes the runbook and the rollback path. Nothing depends on a licence we control.
Nobody before an NDA. Access is read-only until scope is signed, and you can revoke it at any time. The AI tools used on your code, and what each one retains, are listed on the governance page.
Retainers end on 30 days written notice from either side, with no minimum term. Milestone billing means you never pay ahead of delivered work.
Founder, Provingmark
Thirty minutes, no charge.
Related: Fintech app development · Custom software development · AI workflow automation · About Anupam Shah · How we work