Take a bakery group running 14 shops. At the end of the month, the point of sale reports 1,240,000 in sales across the estate. The profit and loss statement shows 1,058,000 in revenue. Nothing was stolen, the bank balance ties out, and every deposit arrived. The 182,000 difference is not an error to hunt down. It is the sum of six or seven perfectly normal accounting treatments that nobody wrote down, and that nobody can reproduce two months later when the auditor asks.
Revenue reconciliation is the control that proves the revenue recorded in your ledger equals what your sites actually sold, once tax, discounts, tips, deferrals and platform commissions have been accounted for. Most guides on the subject were written for software companies reconciling subscriptions. This one is written for businesses that sell goods across several locations, where the number leaves the till already deformed.
Key takeaways
- Revenue reconciliation proves that the revenue posted in the ledger equals what each site sold, after tax, discounts, tips and deferred items.
- A POS daily total is not revenue: discounts, VAT, tips, gift cards, delivery commissions and refunds all change the figure before it reaches the ledger.
- Under IFRS 15 and ASC 606, a gift card sold is a contract liability rather than revenue, and it is recognised when the customer redeems it.
- Reconciling revenue monthly as one consolidated total hides site-level errors, because a single location's misposting disappears into the group figure.
What revenue reconciliation actually means
Ask three vendors and you get three answers. One defines revenue reconciliation as matching completed sales against cash received. Another defines it as matching the general ledger against source billing data. A third treats it as a cash-to-revenue check. All three are describing real tasks, and none of them tells you the thing that matters operationally: where the number changes between the sale and the accounts.
For an operator of physical sites, revenue reconciliation answers one question. The sum of what every location rang up this period, adjusted for the treatments that accounting requires, should equal the revenue line in the profit and loss statement. When it does not, something in between was applied inconsistently, applied twice, or not applied at all.
This is a different job from proving the money arrived. Checking that a site's takings reached the bank account, net of card settlement lag and cash-in-transit fees, is POS cash reconciliation, and it is covered separately in our guide to cash reconciliation software for multi-site businesses. The two controls are complementary. Cash reconciliation catches the missing 230. Revenue reconciliation catches the 12,000 of gift card sales that were booked as revenue in March and should not have been.
Revenue recognition is not revenue reconciliation
Revenue recognition is the rule that determines when a sale becomes revenue. Revenue reconciliation is the control that verifies the rule was actually applied to every transaction. One is policy, the other is proof.
The distinction matters because most operators of restaurants, shops and hotels assume revenue recognition is a concern for software companies with multi-year contracts. It is not. IFRS 15 and ASC 606 apply to any contract with a customer, and a business selling goods across counters generates several categories of transaction where the cash and the revenue land in different periods. Gift cards are the obvious one. Loyalty points, prepaid packages, deposits on catering orders and non-refundable event tickets behave the same way.
The eight places POS revenue deforms
Between the till and the ledger, the figure passes through a series of treatments. Each one is legitimate. The risk is not that they exist, it is that they are applied by hand, differently at each site, and rarely documented.
| Where the number changes | What it does to revenue | The control |
|---|---|---|
| Discounts, comps and staff meals | Rung at full price, then reduced. Gross POS sales overstate revenue. | Reconcile gross sales to net revenue per site, with the discount category itemised. |
| Tax split across rates | The till total is tax inclusive. The ledger posts net, often across two or three rates. | Recompute the tax split from the product mix rather than from a blended rate. |
| Tips and service charges | Collected through the POS but owed to staff. A liability, not revenue. | Separate the tip line at source and post it to the payable, never to sales. |
| Gift cards and vouchers sold | Cash today, revenue on redemption. Booking the sale inflates the month. | Post to a contract liability and release it as redemptions occur. |
| Delivery platform orders | The platform pays net. Booking the payout hides both the sale and the commission. | Split every payout into gross sale, commission and adjustments before posting. |
| Meal vouchers and third-party instruments | Face value collected, net amount reimbursed after the issuer's commission. | Match each settlement batch to the vouchers accepted, and expense the commission. |
| Voids, refunds and credit notes | Reversals often land in a different period from the original sale. | Track reversals against the period of the original transaction, not the period they are keyed. |
| Cut-off on the trading day | A service crossing midnight, or a month ending mid-shift, splits one day across two periods. | Define the business day at site level and apply it consistently at every close. |
Read the table as a checklist rather than a list of problems. Every line represents a rule that either sits in someone's head or sits in a system. When it sits in a system, the reconciliation is a five-minute review of the exceptions. When it sits in someone's head, the reconciliation is a week and the answer changes depending on who did it.
Gift cards, vouchers and anything paid for before it is delivered
When a customer buys a gift card, no goods have changed hands. Under both IFRS 15 and ASC 606, the cash received is recorded as a contract liability, commonly shown as deferred revenue, and revenue is recognised when the card is redeemed. IFRS 15 sets out the treatment of unexercised rights in paragraphs B44 to B47: where a business expects to keep a portion that will never be redeemed, that expected breakage is recognised in proportion to actual redemptions rather than held until the card expires.
This is where a retail estate quietly overstates a good month and understates the next one. Smartbox, the European gift box leader operating across 14 countries with 800 employees, runs precisely this model, and reports four times the previous productivity on its payment-to-invoice reconciliation since automating the match. The volume of prepaid instruments is exactly what makes the manual version unmanageable.
Delivery platforms, where the commission is not a discount
A delivery platform pays you the net amount. That does not mean your revenue is the net amount. Under IFRS 15 and ASC 606, the answer depends on whether you are the principal in the transaction or the platform is, and the assessment turns on who controls the goods before transfer. Where the restaurant is the principal, the customer-facing price is revenue and the platform commission is an operating expense, not a reduction of the revenue line.
Book it the other way and two things break at once. The revenue line understates the business, which distorts every ratio computed from it, and the commission disappears from the cost base, which means nobody ever negotiates it. An agent that bridges delivery platform revenue to accounting splits each payout into its gross sale, its commission and its adjustments before anything is posted.
Reconciling revenue when you run several sites
A single restaurant can reconcile revenue on a spreadsheet. The method survives roughly until the fourth location, then fails for a structural reason: the errors stop being visible in the total.
A group posting 1,240,000 a month across 14 sites is looking at an average of 88,000 per location. If one shop applies the wrong VAT rate to takeaway items for three weeks, the error might be 2,000. Against the group total it is 0.16 percent, which reads as rounding. Against that one site's own numbers it is a control failure that has been running for 21 days and will run until someone opens the site-level detail. The consolidated close is precisely the wrong altitude at which to look for it.
| Reconciliation dimension | Spreadsheet, month-end | Agent-driven, per site |
|---|---|---|
| Level of detail | One consolidated revenue total | Each site reconciled on its own figures |
| Treatment rules | Held by the person who does the close | Encoded once, applied identically everywhere |
| Deferred items | Adjusted manually, often forgotten | Carried and released as redemptions occur |
| Error attribution | Absorbed into the group total | Assigned to the site, period and category |
| What finance reviews | Every line, to find the few that fail | Only the exceptions the agent flags |
| Evidence for the auditor | Rebuilt from memory at audit time | Traced and timestamped as the work happens |
The reason automation changes the outcome is not speed. It is that the same rule gets applied to all 14 sites on the same day, and any line that does not tie out is surfaced with its location attached. Phacet handles this through AI Match, a semantic matching engine that reconciles a payout or a posting to the right site, period and revenue category even when the amounts differ by fees or timing, and exposes its reasoning at each step. An agent that bridges POS revenue to accounting then posts the reconciled result, and the two agents covering revenue recognition and cut-off and electronic meal voucher settlements handle the two treatments that most often go wrong at period end.
What good looks like at the close
A revenue reconciliation is finished when three conditions hold, not when the totals happen to agree.
- Every site is reconciled individually, and the group figure is the sum of reconciled sites rather than a single check performed at the top.
- Every deformation is explained by a rule, not by an adjusting entry someone remembers making.
- Every match is traceable, with the source document, the rule applied and the person who approved the exception recorded and timestamped in a native audit trail.
- Deferred items are carried, not cleared, so unredeemed gift cards and undelivered prepaid orders stay on the balance sheet until the obligation is met.
- Exceptions are reviewed by a human, because a reconciliation that auto-approves its own mismatches is not a control.
The gain from getting there is measured in finance capacity rather than in closing days. La Nouvelle Garde, a group of 10 brasseries, reclaimed two days a week of finance time and deferred planned hires while continuing to open sites. The French Bastards absorbed a move from 7 to 14 bakeries without adding to the finance team. In both cases the constraint that lifted was the manual per-site checking, not the closing calendar.
A control layer on top of your POS and ERP, not a replacement
Revenue reconciliation software should sit above the systems you already run. Phacet connects to the point of sale (Lightspeed, Zelty, Sunday), the delivery and payment platforms (Adyen, Stripe, SumUp), and the ledger (Pennylane, Sage, Cegid), then adds the control between them. Your ERP stays the system of record and keeps posting the entries. What it gains is a check it was never designed to perform: a per-site, per-period verification that the revenue it recorded is the revenue the sites actually earned.
Tax treatment is part of the same layer rather than a separate project, which is why VAT validation runs against the same reconciled data. The approach extends naturally to adjacent controls: accounting cut-off across the wider close, and, for hotel groups, hotel revenue reconciliation and OTA commissions, where the same gross-versus-net question appears in a different form. The full set of controls lives in the general accounting category.
Frequently asked questions
How do you reconcile revenue?
Compare the revenue posted in the general ledger against the sales your source systems recorded for the same period, then explain every difference with a documented treatment: tax, discounts, tips, deferred items, platform commissions and refunds. Anything left unexplained is an exception to investigate, not an adjusting entry to make.
What is the purpose of revenue reconciliation?
Revenue reconciliation confirms that the revenue reported in the financial statements reflects what the business actually earned. It catches misapplied tax rates, sales booked in the wrong period, deferred items recognised too early, and revenue recorded net when it should be gross. It also produces the evidence an auditor asks for.
What are the two types of reconciliation?
Accounting reconciliation is usually split into documentation review, which compares recorded entries against source documents such as receipts and settlement reports, and analytical review, which tests recorded figures against expected amounts based on history or activity. Revenue reconciliation across several sites relies on both.
Does revenue need to be reconciled each month?
Revenue is formally reconciled at each accounting close, usually monthly. The source data should be captured and checked daily, because a site-level error found three weeks later is harder to explain than one caught while the till detail and shift records are still available. Daily site-level controls make the monthly close a review rather than an investigation.
From explaining the gap to controlling it
The gap between the point of sale and the profit and loss statement is not a defect. It is the accumulated result of rules that must be applied, and the only real question is whether your business applies them the same way at every site, every period, with something to show for it afterwards.
Groups that treat revenue reconciliation as a monthly total to force into agreement keep rediscovering the same deformations. Groups that treat it as a set of rules applied per site, with exceptions surfaced to a human and every match traced, stop arguing about the number and start using it. If you run several locations, see the agent that bridges POS revenue to accounting, the wider food and beverage and retail and distribution use cases, or book a demo. Plans start at 299€/month.
