After enough reconciliation cycles, the discrepancies stop looking unique. The package labels change, the products change, the staff change, but the shape of the problem repeats. The same six or seven situations come back week after week. Once I started naming them, the work got faster, because the name carried the fix with it.
This is the quiet value of a taxonomy. A discrepancy that has no name invites improvisation, and improvisation in a state-tracked system is how a small mismatch becomes a compliance note. A discrepancy that has a name points at a procedure. The first question in any reconciliation is not "how do I make these match," it is "which of these am I looking at."
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, not from any one regulator. What differs 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
The reason to classify first is that the fixes are not interchangeable. The correct response to one class is the wrong response to another, and the system will happily let you apply the wrong one.
The clearest example is the line between a sales error and a quantity error. If a sale was recorded with the wrong quantity, the fix is to 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 have now changed the package quantity to paper over a sale that is still wrong underneath. The numbers agree for a moment, and the underlying record is more wrong than before. Two discrepancies that look identical on the surface, a count that is off by one, have opposite correct answers.
A package adjustment corrects a package. A sales receipt corrects a sale. Using one to fix the other is how a one-unit gap turns into an audit conversation.
Turning the list into a habit
The taxonomy only helps if it is in front of you while you work. The practical move is to make the class a required field in whatever you use to track exceptions, a column in a spreadsheet, a tag in a ticket. Before anyone proposes a fix, they have to name the class. That one piece of friction does most of the work, because naming the class forces the diagnosis that the improvised fix skips.
What I learned
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 collapsed a dozen panicked investigations into a handful of known procedures. The hard part of reconciliation was never the fix. It was naming the problem accurately enough that the fix became obvious, and obvious enough that the wrong fix became visibly wrong.