Daily Card and UPI Reconciliation Across ~50 Shops, Posted to the Ledger Only on Approval
Card and UPI settlements from two acquirers, matched to bank credits across roughly fifty shops, split for fee and tax, and posted to the ledger only after a human approves.
Daily card and UPI settlements from two acquiring banks had to be matched against bank credits and posted to the right ledger entity for roughly fifty shops. Done by hand, it consumed accounting staff every morning and still left unresolved items drifting for weeks.
A deterministic matching engine that resolves terminal to shop to ledger branch, matches settlement net against bank credit, splits MDR and GST, and stages a journal for review. Nothing posts without a person approving it.
A morning process that used to be manual reconciliation now presents as a review queue: green rows to confirm, red rows to investigate. Unresolved items carry forward in an aging ledger instead of being forgotten.
What is card and UPI settlement reconciliation?
It is the daily check that the money a shop took actually arrived in the bank. When a customer pays by card, the shop does not receive that amount: the acquiring bank deducts its fee, deducts tax on that fee, batches the remainder, and credits it later - often bundled with other transactions from other days.
Reconciliation matches those settlements back to bank credits, shop by shop, so the books reflect what was really received. Across roughly fifty shops, two acquiring banks, and both card and UPI rails, it is a genuinely hard daily problem.
Why is reconciling settlements so hard at multi-branch scale?
Because the identifiers do not line up. A settlement line names a payment terminal. The ledger names a branch. Nothing connects the two. Multiply that across fifty shops and two banks with different file formats, and the work becomes a morning of manual matching that is too important to skip and too repetitive to do reliably.
Reconciliation is not a data problem. It is a matching problem with real money on the other side of a mistake.
How do you prove an automation will work before building it?
You reconcile a real day by hand first. We took one day of actual settlements, bank statements and point-of-sale exports and proved a deterministic match was possible before writing any software. Only when that day balanced did we design anything.
That step surfaced the real obstacle, which was identity rather than arithmetic. We built the terminal-to-shop-to-ledger crosswalk and resolved every terminal, because a matching engine that resolves ninety percent of terminals is not an automation - it is a new manual task with extra steps.
How does the matching actually work?
In five deterministic steps, with no model guessing in the path. Every rule is explicit and auditable, which matters when the output is a journal entry in a general ledger rather than a suggestion on a screen.
- Resolve the terminal identifier to a shop, and the shop to the correct ledger entity.
- Match the settlement net amount against the corresponding bank credit.
- Split the merchant discount rate and the tax charged on it into their own lines.
- Stage a journal entry against the right entity, and hold it for review.
- Carry anything unmatched into an aging ledger so it stays visible instead of quietly disappearing.
Does anything post to the ledger without a human approving it?
No. Nothing posts unreviewed. The engine could post directly and deliberately does not - every journal is staged and waits for a person. The review screen is built for that decision rather than for admiring the automation: green rows to confirm in bulk, red rows that need a human to look.
This is the principle behind everything we build in this category. Reads are free; writes to a system of record are gated. An automation that posts to a general ledger unsupervised is not a time saver, it is an unreviewed liability. The reasoning is set out on our finance and reconciliation automation page.
What changed for the accounts team?
The morning stopped being a reconciliation exercise and became a review queue. Staff time that went into matching now goes into investigating the small number of rows that genuinely do not match - which is the part that actually needs a person.
The first live posting went through in July 2026, and real data immediately corrected assumptions the design had made, particularly around date conventions and how one acquirer reported transfers to head office. That is normal, and it is why the first live run teaches more than any amount of testing against sample files.
Raw statements, settlement reports and point-of-sale exports are confidential and never leave the client's own infrastructure. If this shape of problem is familiar, it is AI process automation. Talk to us about it.
Frequently asked questions
- Will it post entries to our accounting system automatically?
- Only after a person approves them. The engine matches, splits the fee and tax, and stages a journal against the correct entity - then stops. A human confirms before anything reaches the ledger. Nothing has ever posted unreviewed, and that is a design decision rather than a limitation.
- What happens to transactions that do not match?
- They carry forward into an aging ledger rather than disappearing. Unmatched items stay visible with their age, so a settlement that never arrived becomes obvious instead of quietly vanishing into a rounding difference at year end.
- Does this work with more than one acquiring bank?
- Yes. Parakkat runs two acquirers with different settlement formats through one matching engine. Each format gets its own parser; the matching logic underneath is shared. Adding a third acquirer is a parser, not a rebuild.
- Do we need to change our POS or accounting software?
- No. We read the files your acquirers and bank already produce and post into the ledger you already use. The reconciliation layer sits between them. Nothing about your existing setup has to change.
- Is our financial data safe?
- Raw bank statements, settlement reports and POS exports stay on infrastructure the client owns and are never committed to a repository or copied to our systems. The engagement is governed by an MoU covering confidentiality.
Want a system like Parakkat Jewellers's shipped for you?
Book a 30-minute strategy call. We'll audit your stack, tell you what's leaking revenue, and sketch what a Neogen engagement would look like — no deck, no pressure.
A map of every manual task worth automating
Ballpark ROI on your top 3 automation opportunities
Honest read on whether we are a fit — or who is