A green checkmark in a point-of-sale settings menu tells a dispensary operator almost nothing useful. It confirms the system talked to METRC once, under ideal conditions, during a demo. It says nothing about what happens when the state's seed-to-sale platform stops responding on a Friday evening with a line out the door, which is precisely when most operators discover what their integration actually does.
The sync test everyone runs, and the one nobody does
Most procurement conversations around METRC integration stop at a handful of surface questions: does the POS push package data, does it pull sales, does the dashboard show a status indicator. Those questions matter, but they describe the happy path only. The harder, more useful checklist covers what the register does during an outage, how it handles a mismatched manifest, and whether a refund actually adjusts the state's package quantity or just zeroes out a POS line item while the compliance record drifts quietly out of alignment. Vendors who need a follow-up call to answer the offline-sale question have already answered it.
What a real checklist includes
- Sync direction and frequency: scheduled polling versus manual refresh
- Offline capability: whether the register keeps selling when the METRC API is unreachable, and whether transactions queue for automatic reporting once connectivity returns
- Package reconciliation: flagged at intake, or discovered after a customer has already left with a mismatched unit
- Void and return handling: does the adjustment reach METRC, or only the POS display
- Category and tax mapping: pulled from the package tag, or hand-entered by a budtender during receiving
- Audit trail: a report showing sync timestamps and manual adjustments without filing a support ticket
That offline question carries more weight than any spec sheet. A system built for cannabis retail from the ground up writes the sale locally and reports it once the state system recovers. A system where compliance was bolted on after the fact tends to stop selling altogether, which is the worst possible outcome during a weekend rush with a full waiting room.
Multi-location operators face a different set of failure points
A single-store checklist misses what happens once a business runs more than one location. Internal transfers between a company's own shops generate manifests that must match on both ends, and a single mismatch at opening time can block receiving until someone on the compliance side intervenes manually - while a delivery driver sits in a back hallway waiting. Rate limits compound the problem. Several states throttle how often a POS can call METRC endpoints, and an operator pushing every package change in real time across a dozen stores can quietly exceed that ceiling. Updates stack in a queue, counts drift, and nobody can pinpoint when it happened until the discrepancy surfaces days later during a routine reconciliation.
Shrinkage lives in the gap between the system and the shelf
Inventory shrinkage rarely announces itself. A few units go missing on a Tuesday; by Thursday the count is off by a meaningful margin, and if nobody reconciled package-level data against METRC in between, the trail is cold before anyone thinks to look. This is where audit trails and reconciliation tools earn their cost - not by preventing every discrepancy, but by surfacing it close enough to the event that someone can still ask a useful question. Operators still running that reconciliation through exported spreadsheets on a Sunday night are doing compliance work the hard way, and the lag itself becomes a liability.
Compliance risk doesn't require a mistake to materialize
A store can follow every internal procedure correctly and still end up with a METRC record that's wrong, because a late package sync or an unadjusted return quietly corrupted the state's view of inventory. That exposure sits with the business, not with the budtender who rang the sale. It's why the audit trail deserves as much scrutiny during procurement as the sync feature itself - and why operators switching point-of-sale providers should treat the failure scenarios, not the demo, as the real test.
