Payment reconciliation software for multi-site groups

If you run finance for a group of five to fifty restaurants, hotels or stores, and your card revenue reaches the bank net, batched and two days late, this page is for you. If you are reconciling employee expense cards or a single online checkout, it is not.

Payment reconciliation software is a tool that matches the money a business collected against the money that actually reached its bank account, across every payment method and every source system. For a multi-site operator the hard part is not the bank line: card revenue leaves the terminal gross and arrives net of interchange, scheme and acquirer fees, aggregated by settlement batch rather than by site, one to three days later, and on a separate circuit for American Express. Generic reconciliation tools match a bank line to a ledger entry, which is a two-way match. A group with several sites needs a three-way match instead: the transaction at the terminal, the acquirer settlement, and the bank credit, resolved site by site and terminal by terminal.

Key takeaways

• Across the seven top-ranking pages for "payment reconciliation software", measured on 27 August 2026, the words acquirer, interchange, settlement batch, scheme fee and merchant ID appear zero times.
• Those same seven pages use multi-entity 21 times and multi-site zero times: the category has a word for holding structures and none for groups of physical locations.
• Card revenue reaches the bank net of fees, so a bank feed that loads only the net amount cannot prove that a day of takings was settled in full.
• EU Regulation 2015/751 caps interchange at 0.2% for consumer debit and 0.3% for consumer credit, but Chapter II does not apply to three party card schemes, which is why an American Express flow behaves differently from a Visa or Mastercard flow.
• Phacet reports 88% time saved on gateway reconciliation, moving from one to two days a month to 30 minutes of exception review.

Why multi-site groups fall outside every reconciliation shortlist

Search for payment reconciliation software today and you will find shortlists built for someone else. There is a list for small businesses, several for ecommerce sellers, one for managed service providers. There is no list for a company that takes card payments across twenty physical locations.

This is not an impression. On 27 August 2026 we measured the vocabulary of the seven pages ranking on that query, after stripping navigation, footers, scripts and styles. The term multi-entity appears 21 times across four of those pages. The terms multi-site, multi site and multi-location appear zero times across all seven. The category has built a word for holding structures with several legal entities, and no word at all for a group with several front doors.

The distinction matters because the two problems are not the same. A multi-entity group reconciles intercompany flows between ledgers. A multi-site group reconciles the same legal entity against dozens of terminals, several acquirer contracts and a bank statement that aggregates all of it into a handful of lines per day.

Practitioners describe the result plainly. On a public accounting forum, a bookkeeper handling a merchant processor wrote that trying to reconcile it is "an absolute nightmare" and that they now wait until the end of the month to reconcile the point of sale against the fees (r/Bookkeeping). Waiting a month is not a preference. It is what happens when no tool resolves the flow at the level where the error occurs.

Phacet, which built its card reconciliation agent on this exact problem, describes the failure mode in the same terms: without a daily control, a group discovers tens of thousands of euros of arrears only after several months. The money was never stolen. It was simply never checked.

Multi-site finance is concentrated in a handful of sectors: restaurants, hotels, bakeries, food retail and specialist distribution. If that is your world, the shortlists you have been reading were written for someone whose payments arrive in one place. See how the finance stack of a multi-site food group actually fits together.

What actually happens between the terminal and the bank line

A customer taps a card for 100 euros. Your point of sale records 100 euros of revenue. Your bank account is credited with something else, on a different day, inside a total that also contains three other locations.

Four things happen in between, and none of them are visible on the bank statement.

1. Interchange is deducted. This is the share that goes to the card issuer. Under Regulation (EU) 2015/751, it is capped at 0.2% of the transaction value for consumer debit cards and 0.3% for consumer credit cards.
2. Scheme fees are deducted. These go to the card network itself and are not capped by that regulation.
3. The acquirer margin is deducted. This is what your acquiring bank or payment service provider keeps, and it is the part you negotiate.
4. The remainder is batched and funded. Your acquirer groups transactions into a settlement batch and credits the net amount, typically one to three days later, often across several sites at once.

The consequence is precise and it defeats most reconciliation setups. Another practitioner put it in one sentence on the same forum: with a bank feed pulling revenue through a payment processor, "only the net amount loads in" (r/Bookkeeping). A tool that reconciles the net credit against the ledger will balance perfectly while proving nothing about whether the gross takings were settled in full.

This is why the useful unit of control is not the bank line. Phacet reconciles at three levels rather than two: each transaction to its payout, each payout to the bank credit, and each bank credit to the general ledger entry, breaking every settlement into gross, fees and net. If you want to see that decomposition applied to your own flows, the agent that does it is here: reconcile gateway payouts down to the bank credit.

The three discrepancies a multi-site group cannot see

Once the flow is broken into three levels, the errors that hide inside it become nameable. Phacet's card reconciliation agent isolates three, and they are the three that a monthly bank reconciliation will never surface.

1. Expected commission against actual commission

You negotiated a rate. You are charged another one, or the same one applied to a different base. Because the fee is netted before the credit reaches you, the difference never appears as a debit you could question. It appears as revenue that was slightly smaller than you thought, every day, on every site.

The amounts are not trivial. A retailer publicly broke down a year of processing costs at roughly 47,000 dollars in card transaction fees and 23,000 dollars in ACH fees, and described the total as "31% of our profit" (r/smallbusiness). At that weight, a drift of a tenth of a percent is a real line in the P&L.

2. Days that were never settled

A terminal that fails to transmit its batch produces no error anywhere in your finance stack. The sale happened, the customer left, the point of sale recorded the revenue, and no bank credit ever arrives. There is no alert because nothing failed from the bank's point of view: nothing was ever sent.

This is detectable, but only by comparison. Phacet's rule is explicit: if a day of card sales has no corresponding bank deposit within the expected window, the agent raises a specific alert. Absence of a credit becomes an event rather than a silence.

3. American Express flows lost inside a card line

American Express does not settle like Visa and Mastercard, and the regulation itself recognises the difference. Chapter II of Regulation (EU) 2015/751, which sets the interchange caps, does not apply to transactions with cards issued by three party payment card schemes. The same regulation adds that a three party scheme is treated as a four party scheme when it licenses other payment service providers to issue or acquire, or when it issues through a co-branding partner or an agent.

Operationally, this means a group often runs a separate American Express arrangement, with its own merchant number and its own settlement rhythm, alongside its main acquirer contract. Phacet describes the outcome exactly: American Express and electronic meal voucher flows end up buried inside a single card line on the statement. You are not reconciling a card total. You are reconciling several circuits that were merged before you saw them.

Matching those circuits back apart, per site and per terminal, is what the agent that matches card revenue site by site and terminal by terminal is built for.

And a fourth one, which moves backwards

Chargebacks and refunds belong to the same chain but travel in the opposite direction. A transaction settled in March can be reversed in May, arriving as a debit inside an unrelated settlement, sometimes with a separate dispute fee attached. If nothing provisioned it, the month closes on a revenue figure that a later reversal will contradict.

This is where reconciliation quietly becomes a fraud and accuracy control rather than a bookkeeping chore. A card refund that was never recorded, a duplicate settlement, a terminal whose effective rate drifts on one site only: none of these announce themselves. Phacet's gateway agent surfaces unprovisioned disputes and unrecorded refunds automatically, for the same reason it surfaces a missing batch, because both are absences and absences are only visible by comparison.

How do you choose payment reconciliation software when you run several sites?

Start from what the tool reconciles, not from its feature list. Most categories on the market resolve a real problem competently and simply stop above the layer where a multi-site group loses money. The table below compares tool categories rather than ranking brands, because the right answer depends on which layer you need controlled.

Read that table honestly. If all your card revenue runs through one PSP, that PSP's own reconciliation is excellent and free, and you do not need anything else. If your sites are separate legal entities with clean dimensions in the ERP, a good multi-entity setup will carry you a long way. The gap opens when the same entity collects across many terminals, several acquirer contracts and more than one card circuit.

Three criteria decide it in practice. Can the tool compute an expected fee rather than record the actual one? Phacet works this way: you enter your commission rates by bank or by terminal, the agent calculates the expected variance and only flags what exceeds it, so the noise of normal fees does not drown the anomalies. Can it resolve a batched credit back to the individual sites inside it, which is what semantic matching applied to a batched settlement does? And can it treat a missing credit as an alert rather than a blank?

Two practical criteria decide the rest. The first is integration reach: the tool has to read your point of sale exports, your acquirer settlement files and your ERP without an integration project, which in practice means a plain file drop or an API rather than a connector roadmap. The second is pricing that follows volume rather than seats, because a group adding its twenty-first site should not be repricing its finance stack.

The value of that last question is easy to underestimate until you have measured it. At Astotel, a group of 18 hotels, checking supplier invoices line by line rather than by sampling surfaced 400 euros of billing errors per month on a single supplier, close to 5,000 euros a year. That number comes from purchasing rather than from card settlement, so treat it as an analogy rather than a card figure. The mechanism is identical: nobody finds a small recurring error by looking at a total.

What good looks like at month end

A controlled month does not mean a month without discrepancies. It means a month where every discrepancy was named on the day it happened and closed before the ledger was frozen.

Four outputs make that concrete.

• A daily statement of card revenue against bank credit, per site and per terminal, with the expected fee already isolated.
• A list of days with no matching settlement, raised within the funding window rather than at close.
• A fee variance report showing negotiated rate against effective rate, which is the document you take into a contract renegotiation.
• An audit trail that an external auditor or an accounting firm can follow without you rebuilding the reasoning from memory.

What changes underneath is the workflow itself. The manual version is a spreadsheet rebuilt every month, where someone pastes a point of sale export next to a bank export and sorts until the totals agree. It produces a number, not a control, and its accuracy depends on how tired the person was on the day. The automated version inverts the burden: the matching runs daily against your own rates, and a person only sees what failed.

That inversion is the actual point of automation here: not fewer people, but a control that runs on the day the error happens instead of three weeks later. That is also what makes real-time useful rather than decorative. A dashboard that shows yesterday's settlement gaps is actionable, because your acquirer can still explain a batch from two days ago. The same dashboard at month end is archaeology.

The time this frees is measurable. On gateway reconciliation, Phacet reports 88% time saved, moving from one to two days per month to 30 minutes of exception review. The work does not disappear. It changes shape, from matching rows to deciding on the handful of rows that did not match.

Smartbox, a European gift box leader with 800 employees across 14 countries, ran the same shift on payment and invoice matching and reported four times the productivity, with each use case operational in six weeks. Their operations director, Mourad Meraou, put it this way: "Phacet operates as an extension of our teams." The detail worth noting is the six weeks: this is a control you install, not a migration you survive. See the full account of what four times productivity on payment matching looked like.

A control layer on top of your POS, your acquirer and your ERP

None of this argues for replacing anything. Your point of sale records sales correctly. Your acquirer settles correctly. Your ERP posts correctly. Each of them is right about its own perimeter, and none of them is responsible for the space between them.

That space is where a control layer belongs. It reads the exports you already produce, applies the rules you already negotiated, and tells you where the chain broke. Your systems keep doing their job, and something finally checks the handover between them.

Can AI do bank reconciliations?

Yes for the matching, and only partly for the judgement. Machine matching is genuinely better than a human at resolving thousands of rows against several sources, including when labels, dates and amounts do not line up. It is not better at deciding whether an unexplained 180 euro gap on one site is a fee change, a failed batch or a mistake worth calling the acquirer about. That decision stays with the finance team, which is why every match Phacet produces carries its reasoning and its source, and why the agent proposes while a person disposes.

It is also worth being clear about general purpose assistants. Claude and ChatGPT are remarkable tools, but they do not know your acquirer contracts, your terminal fleet or your accounting rules, they produce no audit trail, and they do not connect to your mailbox or your SFTP. Phacet's 40+ agents were built on 100+ finance deployments in production, and the reconciliation ones exist because customers hit these exact walls. What that means for a treasury function specifically is set out on the treasury view of what a reconciliation tool actually needs to do.

From reconciling to controlling

Reconciling is proving that two numbers agree. Controlling is knowing, on any given morning, that yesterday's takings across every site arrived in full, that the fees charged were the fees agreed, and that no terminal went quiet. The first is an accounting obligation. The second is what stops a slow leak from becoming a discovery at year end.

The gap between them is not a software feature. It is a decision about which layer you choose to watch. At La Nouvelle Garde, a group of ten brasseries, CFO Théo Richard describes what that shift produced for his team: "Phacet is like a member of the team, operating 24/7." The point is not that the work disappeared. It is that someone is now watching the layer nobody was watching. The full La Nouvelle Garde account sets out how that started.

If you want to see that layer applied to your own settlements, start with the agent that reconciles gateway payouts down to the bank credit, and bring one month of exports.

Frequently asked questions

What is the best software for payment reconciliation?

There is no single best tool, because the right one depends on what you need reconciled. If all card revenue runs through one payment service provider, that provider's own reconciliation is usually enough. If you collect across several sites, terminals and acquirer contracts, you need a tool that resolves transaction, settlement and bank credit as one chain.

Why does only the net amount load into my bank feed?

Because your acquirer deducts interchange, scheme fees and its own margin before funding you, then credits the remainder as a single batched amount. The bank feed reports what arrived, not what was collected. To recover the gross figure you have to bring in the settlement report from the acquirer, which is a separate file from the bank statement.

How do I account for payment processing fees?

Record the gross sale as revenue and the deducted fee as a separate operating expense, rather than posting only the net credit. Posting the net amount understates revenue and makes the fee invisible, which means a rate change can never be detected. Keeping the two apart is also what allows an effective rate to be compared against a negotiated one.

Does QuickBooks have a reconciliation tool?

Yes, QuickBooks reconciles bank and credit card accounts against statements, and it does that well for a single account. Its limit for a multi-site operator is granularity: it matches at account level, so a batched settlement covering four locations arrives as one line, and per-site or per-terminal variance stays out of reach.