A package reads as missing. The shelf has it, the POS shows it, and METRC cannot find it. The instinct is to start adjusting quantities and treat the gap as a counting problem. Most of the time it isn't one. The product never moved; the connection between the two systems did.
A lot of what looks like an inventory discrepancy is actually an authentication, mapping, or timing failure showing up as a bad count. If you reach for a quantity adjustment first, you are editing a number that was probably correct to paper over an integration problem, and the gap comes right back the next day.
The four failure modes
The integration layer fails in a handful of recognizable ways, and each one shows up as "the count is wrong."
Authentication
The connection between a POS and METRC runs on an API key. Keys expire, get rotated, or get created without the permissions the workflow needs. When that happens, sales or adjustments stop posting and the discrepancy tools can go suspiciously empty. It reads like inventory drifting out of sync, but nothing has synced at all since the key went stale. Before you look at any count, check whether the key is valid and carries permission for sales, packages, transfers, and adjustments.
Mapping
A POS product has to be mapped to a METRC item, a category, and a unit weight. When the mapping is wrong, a product will refuse to import, sync to the wrong item, or report under the wrong category. That is not an inventory error and changing a quantity won't fix it. You fix it upstream in the product setup, before you retry the sync. Forcing the count to look right just buries the real defect under a manual correction.
Timing
METRC and the POS don't always update in the same instant. A timeout, a queue delay, or a batch that posts later can leave a sale visible in one system and not yet in the other. Given a few minutes it usually resolves itself. The danger is acting inside that window: you record a manual fix for a sale that was about to post, and now the transaction is counted twice.
Duplication
A double-clicked receive, a timeout followed by a manual retry, or a CSV upload that overlaps an API push can post the same receipt or manifest twice. Inventory then depletes or arrives twice over, and no physical recount will explain the gap, because the product on the shelf is fine. Find and remove the duplicate record. Don't adjust the quantity to split the difference.
Symptoms and where to look first
Before touching a quantity, match the symptom to the cause that usually isn't about inventory at all.
| What you see | Likely non-inventory cause | First check |
|---|---|---|
| Sales or adjustments stopped posting; discrepancy tools empty | Expired or under-permissioned API key | Validate the key and its permissions before anything else |
| Product won't import or syncs to the wrong item | Category, item, or weight mapping error | Inspect the product mapping, not the count |
| Sale exists in one system only | Timing or batch-posting delay | Wait, then check the audit log before acting |
| Inventory depleted or received twice | Duplicate post from a retry or overlap | Confirm the receipt/manifest ID in METRC, then remove the duplicate |
| Pre-rolls flagged for weight mismatch | Unit weight includes packaging; POS weight is cannabis-only | Verify physical weight; reconcile the definition, not the count |
The pre-roll false positive
The pre-roll row generates a steady stream of investigations into a problem that isn't real. Some POS platforms record the cannabis weight of a pre-roll, while the METRC unit weight can reflect the full weight including the paper and filter. Those two numbers were never going to match, and no amount of counting reconciles them. It's a definition mismatch, not an inventory loss, and recognizing it saves you an hour of recounting a shelf that was always correct.
When the adjustment is actually right
None of this means quantity adjustments are never the answer. Sometimes the count genuinely is off from moisture loss, a miscount, or a scale that drifted. It's a question of order. Authentication, mapping, timing, and duplication are all cheaper to rule out than a physical recount, and they are where the cause usually turns out to be. The inventory adjustment is the last thing to reach for, because it quietly rewrites a number that may have been correct all along.
What I learned
On the reconciliation work I did, the habit that paid off was asking whether the two systems were even talking before counting anything. The volume of "missing inventory" dropped once I stopped assuming the shelf was wrong. Most of it had never been missing; the connection between the systems was what needed the attention.