Reconciliation
Reconciliation Engine
Two independent records of the same event, aligned by time, station and SKU. Where they agree, nothing is reported. Where they diverge, that difference is the entire product. The engine reports variance rather than blame — sustained negative variance flags leakage, positive variance flags under-pouring or a measurement problem worth fixing. Your POS is one writer into the ledger, not the authority over it.
The problem
Every business reconciles. What came in against what was sold. What was ordered against what arrived. Where both records are digital, software solved this decades ago.
At the bar, one of the records is physical — a hand, a bottle, a glass — so there has never been anything to reconcile against. The till has been both the record and the check on itself, which is not a check at all.
The Reconciliation Engine gives the till a counterparty.
Overview
The camera is the interesting part. The matching engine is the part that lasts.
The Reconciliation Engine takes the vision ledger and the POS ledger, aligns them in time and by station and SKU, and reports where they disagree. Matched events cancel. Unmatched events become variance. It does not decide who is right, because reporting divergence and adjudicating blame are different products and only one of them survives contact with a bar manager.
Critically, the engine has no POS integration. It has a ledger interface, and the point-of-sale is one writer into it. So is your inventory system. So is a distributor invoice. So is a manual stock count typed in at close. Each supplies the same shape — event, time, location, SKU, quantity, and a tag saying who asserted it.
That is what makes adding a POS a connector rather than a project, and it is what stops any single vendor relationship from holding your venue hostage. It is also the layer that accumulates: the knowledge that a 750 ml bottle nominally yields 12.5 pegs, that a cocktail decrements three SKUs at once, that a 2 a.m. stock count covers a window that has already closed.
Who it is for
Primary
Any venue running Barvis-X1 — the engine is what turns a count into a finding, so in practice it ships together.
Standalone
Multi-outlet operators who want stock, invoices and POS reconciled against each other before any camera goes in. No hardware, no install, no camera in the room.
Buyer inside the business
The owner, or the finance person who already reconciles everything else in the business and finds the bar’s exemption from that discipline strange.
What it does
Aligns records
Vision, POS, inventory, invoices and manual counts, by time, station and SKU.
Reports variance, not blame
Negative variance flags leakage. Positive variance flags under-pouring or a measurement problem — and yes, we report that too, because a system that only ever finds theft is not measuring, it is confirming.
Works over windows
Shift, station, SKU or bottle. Never a single drink.
Treats every source equally
No writer is privileged. Provenance travels with every record.
Handles the awkward cases
Cocktails as recipe-based multi-SKU decrements, comps as an authorised event type, opened-bottle carry-over across shifts.
Produces a weekly report
Reviewed with the operator before anything is acted on.
What you get
A number with a location
“Station 2, Fridays, on one SKU” instead of “we are down four bottles this month”.
A trend line
Variance over weeks is what separates a bad night from a pattern.
A clean bill when it is clean
Most weeks, on most stations, the records will agree. That is a result.
A single ledger
Stock, invoices, POS and vision in one place, which is worth something on its own even before variance.
Independence from your POS vendor
Change POS and the product keeps working.
Specifications
Inputs
Vision ledger, POS ledger, inventory system, distributor invoices, manual stock counts.
Interface
One ledger interface. Every source is a writer; none is authoritative.
Alignment keys
Timestamp, station or location, SKU.
Reporting windows
Shift, day, week, station, SKU, bottle.
Output
Variance report with provenance on both sides of every divergence.
No-POS mode
Reconciliation against manual stock counts at coarser resolution.
Audit trail
Append-only. Every state-changing action recorded with actor and timestamp.
Data residency
Indian region (AWS ap-south-1, Mumbai).
Offline behaviour
Events queue locally and sync on reconnect.
What it does
not do
It does not accuse.
It reports two records and the gap between them.
It does not treat the POS as truth.
Neither record is privileged.
It does not require a POS at all.
Manual stock counts work, at lower resolution.
It does not file anything on your behalf.
It produces data that supports your excise and GST filings; it does not submit them.
It does not act automatically.
Every report is reviewed before it becomes a decision.
Barvis counts every pour at the bar and reconciles it against the till
All products