After enough reconciliation cycles, the discrepancies stop looking unique. The labels and products and staff change, but the same six or seven situations come back week after week. Once I started naming them, the work got faster.
A discrepancy with no name invites improvisation, and in a state-tracked system that is how a small mismatch turns into a compliance note. A named discrepancy points at a procedure instead. So the first question in a reconciliation is which of these you're looking at, not how to make the numbers match.
The classes that actually repeat
Across METRC states, the high-volume discrepancies fall into a short list. The fields and labels are identical state to state because they come from the platform rather than any one regulator. What changes by state is the rulebook around them, not the shape of the mismatch.
| Class | What you see | Fix family |
|---|---|---|
| Quantity mismatch | METRC quantity ≠ POS quantity ≠ shelf | Physical count decides the truth; correct the system that is wrong |
| Active in METRC, missing in POS | Package exists in METRC but cannot be sold in the POS | Build or map the product, import the package, refresh the sync |
| In POS, missing in METRC | POS shows stock METRC cannot locate | Check for a typo'd tag or wrong license; refresh; retire the bad POS record |
| Item / category / weight mismatch | Product maps to the wrong item; oversell or sell-block warnings | Correct the mapping; if the metadata is wrong at the source, contact the supplier |
| Transfer / manifest error | Wrong package, quantity, or price on a manifest | Edit or void before receipt; reject the mismatched package on receipt |
| Sales receipt error | Wrong quantity, price, time, or customer type on a sale | Edit or void the receipt in the sales workflow; never package-adjust a sale |
| Conversion / production-batch error | A new package loses its lab results or shows an untested status | Review the package genealogy; use processing jobs only when a real category change requires new testing |
| Lab / test-status mismatch | Untested product looks sellable, or tested product looks blocked | Verify in METRC first; stop the sale if needed; import or re-sync lab data |
| Duplicate receipt or manifest | The same sale or transfer appears twice | Confirm the record ID in METRC before voiding anything; check the audit log |
Why the name matters
Classify first because the fixes are not interchangeable, and the system will let you apply the wrong one against the wrong class.
Take the line between a sales error and a quantity error. If a sale was recorded with the wrong quantity, you edit the sales receipt; the platform is explicit that sales mistakes belong to the sales workflow. If you instead "fix" it with a package adjustment, you've changed the package quantity to paper over a sale that is still wrong underneath. The numbers agree for a moment and the record is worse than before. Two discrepancies can look identical on the surface, a count that is off by one, and have opposite correct answers.
Making it a habit
The list only helps if it's in front of you while you work. Make the class a required field in whatever you use to track exceptions, a column in a spreadsheet or a tag in a ticket. Before anyone proposes a fix, they have to name the class. Naming it forces the diagnosis that an improvised fix skips.
Closing note
The discrepancies were never as varied as they felt in the moment. Most of the apparent complexity came from treating each one as new. A short shared vocabulary turned a dozen investigations into a handful of known procedures. The hard part was rarely the fix; it was naming the problem accurately enough that the right fix followed.