Schedule a demo

Pick a time with our team. The scheduler is provided by Calendly and sets its own cookies.

Prefer email? support@coriunder.com

We use your details to arrange your demo. Read our Privacy Policy.

Reconciliation System

Every provider, one set of books.

Pull the file from every acquirer, provider and scheme you work with, match it against what the platform recorded, and turn the differences into real financial entries. Reconciliation is not a report you run at month end. It is the engine that feeds settlement.

Reconcile the files of the acquirers you work with

Nuvei
Finaro
Silverflow
Checkout.com
Stripe
Yapily
Paysafe
Rapyd

One engine, not one integration per provider

Each provider sends a different file in a different shape on a different schedule. They all land in the same reconciliation model, so your operators learn one screen and your finance team reads one number.

20+

Acquirer formats built in

8

Dispute entry types

4

Ways a file arrives

1

Path into settlement

What it does

The difference between the file and the truth

Reconciliation exists to answer four questions. Did every transaction we recorded actually settle? Did anything settle that we never recorded? Were we charged what we agreed? And what do we owe the merchant once all of that is accounted for?

1Files arrive four ways

SFTPPulled

APIFetched

WebhookReal time

UploadOperator
2Map a new format on screenNo release
Reference
col 3
Amount
col 7
Currency
col 8
Status
col 11
Delimiter;ApprovedAPPRDeclinedDECL
3Every route, one record
Acquirer ASettlement file · SFTP4,812 rowsImported
WalletReport · API1,206 rowsImported
BankStatement · upload38 rowsMapping

Every provider, one model

Acquirers, alternative payment methods, wallets, banks and payout vendors each report in their own format and on their own clock. Files arrive four ways - pulled over SFTP, fetched from the provider API, pushed in real time by webhook, or uploaded by an operator - and every route lands in the same reconciliation record. Formats we have not met before do not need a release: an operator maps which column holds the reference, the amount, the currency and the status, sets the delimiter and the approved and declined tokens, and imports. Adding a provider means adding a source, not rebuilding your month end.

See the integrations
1Match on any stored reference
auth 8841QK
→
TX 9920114
Matched
ARN 7448…102
→
2 candidates
Not applied
2The majority reconciles silently
Match rate
99.9%
To review
7
3Exceptions, sorted by what is wrong
€340.00In file, not in platformOrphan
€1,120.50Captured, never settledMissing
€74.20Authorised €79.00Amount
€500.00Settled, recorded declinedMismatch

Matching, and the exceptions that matter

Rows are matched back to the transaction that produced them on any of the references the platform stored at authorisation - approval number, debit reference, acquirer reference. When a row matches more than one transaction the engine says so and refuses to apply it, because a confident wrong match is worse than an exception. The matched majority reconciles silently and your team gets the remainder, separated by what is actually wrong: rows in the file with nothing behind them, transactions that never appeared in a file, amounts that differ from what was authorised, and the one nobody expects - transactions the acquirer settled that your platform recorded as declined.

Transaction management
1Dispute lands in the fileTX 9871204
CB
€340.00 chargeback
Fraud · card absent environment
Chargeback
2Each stage posts its own entry
Original salehistory kept+340.00
Chargebackown row-340.00
Scheme feeown row-15.00
Recoveryif represented+340.00
3Ratio counts what actually counts
ChargebackPre-arbArbitrationin ratio
DeterrentRefund-styleposted, kept out

Disputes arrive as money, not as a note

When a dispute lands in a reconciliation file it becomes its own financial entry rather than a flag stamped on the original sale. Chargebacks, representments, pre-arbitration, arbitration and every recovery each post their own row with their own amount and their own fees, so the original transaction keeps its history and the ledger keeps its arithmetic. Deterrent and refund-style resolutions post separately too, deliberately kept out of your chargeback ratio because they never counted against it.

Risk and rules
1Escalates on its ownEach announced once
72h→24h→Expiry€340.00 · due 22h
2Nothing lost in transit

WebhookReal-time changes

SweepEvery 15 min + catch-up
3Merchant advises, you decide
Dispute work queue3 urgent
€340.00Evidence via ticketDue 22h
€1,890.00Defence draftedDue 2d
€120.00Auto-defendedSubmitted

A deadline you cannot miss by accident

An unanswered dispute closes against you automatically, so the platform treats the response window as the organising principle. The deadline for the current stage is stored the moment it is known and escalates on its own at seventy two hours, at twenty four, and at expiry, each announced once. A webhook delivers changes in real time and a sweep re-checks every open case every fifteen minutes with a rolling catch-up, so a notification lost in transit never costs you a case. The merchant supplies evidence and a recommendation through a ticket, your operator keeps the final accept-or-defend decision, and merchants who should always be defended can be set to defend automatically.

The operator console
1Cost arrives later, in the file
TX 9920114€1,249.00 · VisaCost attached
Interchange
€2.50
Scheme fee
€0.89
ARN
7448…102
2Coverage by acquirer and currency
Acquirer A · EUR184,210100%
Acquirer A · GBP61,940100%
Acquirer B · EUR92,78084.7%
Acquirer C · USD45,100100%
3The gap, and how old it is
Acquirer B · no cost
€14,220
Oldest gap
19 days
Past the 14-day threshold

What it actually cost you

Your real cost is not knowable at the moment you take a payment. It arrives later, in the file. Reconciliation writes it back onto the transaction it belongs to - interchange, scheme fee and the acquirer reference - so cost sits against revenue at the row level rather than as a monthly lump. What that buys you is a coverage number: how much of your settled volume still has no cost attached, broken down by acquirer and currency, with the age of the oldest gap. A month covering sixty percent of volume and one covering ninety nine look identical on a profit line, and only this tells them apart.

How pricing works
1Reconciliation moves the status
TX 9920114
matched to Acquirer A file
Unpaid by scheme→Paid
2Choose how strict settlement is
Pay matched rows onlyOn
Stop while funding unreconciledNeeds approval
3Statement lines trace to rows
Chargebacks-2,180.00
Representments-1,240.00
Pre-arbitration-340.00
Net payout163,577.38

Built into settlement, not bolted beside it

This is the part most platforms leave to a spreadsheet. Reconciliation is what moves a transaction from unpaid by the scheme to paid, and settlement pays from the paid side, so the two are the same system rather than two systems that agree on a good day. You can go further and have settlement pay only what reconciliation matched, or refuse to run at all while funding movements are still unreconciled until someone approves it deliberately. Each dispute type keeps its own line on the merchant statement, so a representment is never folded into chargebacks and a recovery is never mistaken for a sale.

Settlement management
How it works

From provider file to net payout

1

Collect

Each provider's file or feed is picked up on its own schedule and parsed into the shared reconciliation model, whatever shape it arrived in.

2

Match

Rows are matched to the transactions that produced them by provider reference. Anything that does not match cleanly is queued as an exception with the reason it failed.

3

Post

Disputes, recoveries and adjustments become financial entries with their own amounts and fees. The real cost of each transaction is captured and split into its components.

4

Settle

A matched row is what marks a transaction paid by the scheme, and settlement pays from there. Every statement line traces back to a reconciled row, each dispute type on its own line.

In the box

What the finance team gets

Four ways in

SFTP, provider API, real-time webhook or operator upload, one destination.

Ambiguity guard

A row matching two transactions is flagged, never auto-applied.

Exception queue

Unmatched and mismatched rows separated by reason, not lumped together.

Dispute entries

Each dispute stage posts its own financial row with its own fees.

Deadline tracking

Response windows stored per stage and surfaced as an ordered work queue.

Evidence handling

Merchant evidence collected through a ticket and submitted to the provider.

Cost written back

Interchange, scheme fee and acquirer reference stamped onto the transaction.

Coverage reporting

How much settled volume still has no cost data, by acquirer and currency.

Statement lines

Each dispute type on its own settlement line, never folded into one figure.

Run reports

Updated, not updated, mismatched and settled-but-declined, per batch.

Mapped imports

Map a new acquirer's columns on screen and import it. No release needed.

Idempotent posting

A row can arrive twice and only post once. Re-running a file is safe.

Send us last month's file.

Bring a real settlement file from any provider you work with and we will run it through the engine with you, exceptions and all.

For your developers

Every payment call, documented.

The developer center carries the API reference for payment processing, integration guides for hosted pages, iframes and server to server, a payment method wizard that generates the code, signature validation tooling and response simulation for testing before you go near production.

  • API reference
  • Integration guides
  • Payment method wizard
  • Code generation
  • Signature validation
  • Response simulation
  • Testing sandbox
Documentation devcenter.coriunder.cloud Open the developer center

Frequently asked questions

  • Does this work across more than one acquirer?

    That is the reason it exists. Most platforms reconcile one processor well and everything else by hand. Here every provider you work with feeds the same engine, so a merchant processing across several acquirers still produces one reconciled position and one statement.

  • What happens to a row that will not match?

    It is recorded with the reason it failed and surfaced in the reconciliation reports, split by kind: a row in the file with no transaction behind it, a transaction that never appeared in any file, an amount that differs from what was authorised, and a transaction the acquirer settled that the platform recorded as declined. These are four different problems and they are kept apart so they can be worked differently. Reconciliation records are read-only by design, so the fix happens on the transaction or with the provider, never by editing the evidence.

  • Why post a dispute as a separate transaction?

    Because a dispute is a movement of money, not a property of the original sale. Marking the original as disputed loses the amount, the fees and the sequence when a case runs through several stages. Separate entries keep the original sale intact, let each stage carry its own cost, and let a later recovery reverse the right amount.

  • Do all dispute types count towards the chargeback ratio?

    No, and that distinction is deliberate. Genuine chargebacks and the stages that follow them count. Deterrent and refund-style resolutions, the ones designed to settle a case before it becomes a chargeback, are posted so the money is right but kept out of the ratio, because they were never counted against you in the first place.

  • How does this connect to settlement?

    Directly, and it is enforced rather than assumed. A transaction counts as paid by the scheme only once reconciliation matches it, and settlement pays from that side. Depending on how the programme is configured, settlement can be restricted to reconciliation-matched rows only, or blocked entirely while funding movements remain unreconciled until an operator approves the exception. Each dispute type then gets its own statement line.

  • Can we see what a provider actually charged us?

    Yes, at transaction level. Interchange and scheme fees come in on the file and are written back onto the transaction they belong to, and where an acquirer reports a fee that differs from what the transaction already carries, an operator is shown both figures side by side and decides. Settled transactions are never rewritten, because the statement the merchant already received was calculated from the figure as it stood.

  • What if the same file gets loaded twice?

    Nothing doubles. Posting is keyed on the provider's own reference for the row, so a repeated file or a retried run recognises what it has already processed and posts only what is genuinely new.

Still have a question?
Watch it in the product

Short walkthroughs from the admin

All tutorials

Reconciliation

Chargeback deadlines

Balance requests and the ledger

Close the month in an afternoon.

Reconciliation and settlement are one system here. We will show you both with your own numbers in them.

Provider coverage depends on your setup. Talk to our team about the providers you work with today.