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, to treat the gap as a counting problem. Most of the time, it is not. The product never moved. The connection between the two systems did.
This is the single most useful reframe in track-and-trace work. A surprising share of what looks like an inventory discrepancy is really an authentication, mapping, or timing failure wearing an inventory costume. If you reach for a quantity adjustment first, you are editing a real, correct number to compensate for a plumbing problem that will simply recreate the gap tomorrow.
The four costumes
The integration layer fails in a small number of recognizable ways, and each one presents 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. The symptom looks like inventory drifting out of sync. The cause is that nothing has synced at all since the key went stale. The first check is not the count, it is 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. None of that is an inventory error, and none of it is fixed by changing a quantity. It is fixed upstream, in the product setup, before any sync is retried. Forcing the count to look right just buries the real defect under a manual correction.
Timing
METRC and the POS do not 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 resolves itself. The danger is acting inside that window, recording a manual fix for a sale that was about to post, and ending up with the transaction counted twice.
Duplication
The mirror image of timing. 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. Now inventory depletes or arrives twice over, and the count is wrong in a way no physical recount will explain, because the product on the shelf is fine. The fix is to find and remove the duplicate record, never to adjust the quantity to split the difference.
A first-check table
Before touching a single quantity, run the symptom against its likely non-inventory cause.
| 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
That last row deserves a sentence of its own, because it generates a steady stream of investigations into a problem that is not 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. The two numbers were never going to match, and no amount of counting will reconcile them. It is a definition mismatch, not an inventory loss. Recognizing it saves the hour you would have spent recounting a shelf that was always correct.
Stale data is more dangerous than missing data, because stale data looks complete. It invites you to fix the wrong problem with full confidence.
Touch inventory last
None of this means quantity adjustments are never right. Sometimes the count genuinely is off: moisture loss, a miscount, a scale that drifted. The point is one of order. Authentication, mapping, timing, and duplication are cheaper to rule out than a physical recount, and they are where the real cause usually lives. Check the connection first, the mapping second, the clock third. The inventory adjustment is the last tool you reach for, not the first, because it is the one that quietly rewrites a number that may have been correct all along.
What I learned
The fastest reconciler I worked with almost never started by counting. They started by asking whether the systems were even talking. Once I copied that habit, the volume of "missing inventory" dropped, not because the inventory improved, but because most of it had never been missing. It had been disconnected, mismapped, delayed, or doubled. The product on the shelf was usually telling the truth. It was the connection between the two systems that needed the attention.