POS reconciliation matches each receipt from a retailer's point-of-sale system with the payment notification sent by the terminal or acquirer. Matcher™, part of NORBr's white-label payment infrastructure, lets ISVs, PSPs and acquirers serving retailers offer that matching automatically, with match-later and withdraw actions and a full audit log, under their own brand.
Store payments look simple until the end of the day, when the cash register's figures have to agree with what the terminals actually processed. This article explains why POS reconciliation is hard, how Matcher™ matches receipts with payments, how it handles split, partial and delayed payments, what happens to transactions that cannot be matched, what your merchants' teams get, how it was built with a retailer's payment team, and how it fits into a white-label payment infrastructure.
What is POS reconciliation and why has it become harder?
POS reconciliation is the daily check that every sale recorded by the cash register system has a matching card or wallet payment, and that every payment belongs to a sale. When the two disagree, the store's books are wrong, and someone has to find out why.
It used to be a one-to-one pairing: one register, one terminal. Mobile POS devices, several terminals per store, split payments and orders taken by phone broke that pairing, so a receipt and its payment can now arrive from different devices, at different times, in different files. Mobile acceptance keeps growing: Research and Markets (January 2026) projects the global mobile POS terminals market to grow from 37.88 billion dollars in 2025 to 114.59 billion dollars by 2031.
How does Matcher™ match POS receipts with payment notifications?
Matcher™ receives the receipts from the retailer's POS system, often as batch files, and the payment notifications from terminals and acquirers, often in real time. In a typical setup, a sale on day 1 creates a ticket in a POS system such as CEGID and a payment notification from a provider such as Adyen; on day 2, NORBr receives the batched CEGID file overnight alongside the real-time Adyen notifications and runs the matching. Volumes make this unavoidable: according to the ECB payments statistics published in July 2026, the euro area counted around 25.7 million POS terminals at the end of 2025, 24.6 percent more than a year earlier.
Matcher™ applies a cascade of matching strategies, from the most precise to the most tolerant.
- By reference: the receipt and the notification share an exact payment identifier.
- By merchant order reference: the order ID links both records.
- By data: amount, store, payment method and a date window agree.
- By pairing: a transaction is offset by an opposite movement, such as a sale and its refund.
Records that meet the criteria are marked as reconciled automatically. Store managers and accountants only review what remains, in the Matcher™ interface, and match it manually with a stated reason.
How are split, partial and delayed payments reconciled?
Real store payments rarely arrive one to one, so Matcher™ handles several patterns. When one sale produces several terminal notifications, it aggregates them and confirms the match when their combined amount equals the receipt. When one ticket is paid with two methods, such as a card and a digital wallet, it links them on the combined total.
Partial payments are completed when the remaining amount lands, standalone refunds are linked to their original sale by reference or by amount, store and date, and offline or out-of-order data is matched on a date window rather than on real-time timing.
Mail and telephone orders (MOTO) show why the date window matters. On day 1, the customer pays by phone and Adyen sends the notification, but no POS ticket exists yet. On day 2, the store clerk enters the ticket in CEGID. On day 3, Matcher™ matches both records automatically if ID, date, amount and payment method agree; if data is missing, the team completes it and matches manually.
What happens to transactions that cannot be matched?
They are never dropped silently. A transaction waiting for missing data can be set to Match later, with a reason and a comment, and stays visible in a pending queue until the information arrives.
A transaction that will never match can be withdrawn with a documented reason: it leaves totals and further matching but stays in the logs. Withdrawal requires a dedicated permission, and every action, automatic or manual, is written to an immutable log with timestamp, identifier, user and action type. An exportable audit file can be generated at any time.
What do your merchants' store and finance teams get?
Each team gets a shorter, more reliable part of the close. Store staff spend less time checking tickets against terminal printouts, store managers get end-of-day figures they can trust, accountants work only on exceptions, and finance leaders see one consistent view across stores and channels.
For the ISV, PSP or acquirer offering it, Matcher™ becomes part of the retail product sold under its own brand. The same matching layer covers e-commerce and physical store accounts, and reconciled store payments flow into reconciliation and settlement with the rest of the merchant's activity. The automated reconciliation article covers that settlement side.
How was Matcher™ built with a retailer's payment team?
Matcher™ was developed with the payment team of a major retailer whose store processes changed when mobile POS devices arrived. Jocelyn, Head of Payment at that retailer, explains: "We decided to progress towards a solution that integrates our POS and payment systems, as no such solution was available on the market. Our collaboration with NORBr has been crucial in this endeavor. The NORBr team perfectly understood our business needs and the data sets and rules we provided. Their expertise allowed us to rely on their recommendations for the user interface and the implementation of an easy-to-use workflow for the end user. This project may seem simple in theory, but its implementation is complex due to the variety of special cases we encounter in real situations. What stands out from this development phase is the team's adaptability to the unexpected."
She adds: "The NORBr team not only brought their payment expertise but also the necessary adaptability and responsiveness, ensuring the success of the Matcher™ project. The introduction of mobility with the mPOS system disrupted our traditional processes, and NORBr's solution has been instrumental in addressing these challenges." And: "Matcher™ is destined to become the reference in all internal workflows associated with payment."
How does Matcher™ fit into a white-label payment infrastructure?
Matcher™ is the in-store reconciliation layer of NORBr, the white-label payment infrastructure for PayFacs, PSPs, ISOs and ISVs. It shares the same transaction records as routing, checkout and online reconciliation, so in-store and online payments are reconciled with one logic and reported together.
Operators building an omnichannel offer can start from the In-Store Payments & Matcher™ page and the omnichannel coverage solution. The article on scaling in-store payments across countries covers terminals, certifications and local rules.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
