Most reconciliation routines I have watched run three stages and call it four. They detect a discrepancy, sometimes they classify it, then they correct it and close the ticket. The stage that gets dropped is verification, which is the one that tells you whether the fix held.

A reconciliation that holds runs four stages in order: detect, classify, correct, verify. Skip detection and you correct things at random. Skip classification and you apply the wrong fix for the class of problem you actually have. Verification is the easy one to skip, because by the time you get there the screens already agree, and skipping it means you never learn that your correction created a second discrepancy somewhere else.

Detect

Detection is a comparison, not a floor walk. You line up two exports and let the mismatches surface. This is the daily pass, and it has a fixed shape:

  • Sales audit. Compare completed POS sales against METRC receipt IDs. Isolate any sale with a blank external ID, that is a sale that may never have reached METRC.
  • Package audit. Compare active package labels and quantities between the two systems. This catches missing imports, finished packages still showing as sellable, and quantity drift.
  • Manifest audit. Review every transfer created or accepted that day. Confirm shipped quantity against received quantity while the transfer is still fresh.

What comes out of detection is a list of things that need a human to look at them. Nothing is decided yet.

Classify

Each item on that list gets a name before anyone proposes a fix. Is it a sales error, a quantity error, a manifest error, a mapping error, a conversion error, or a sync failure? The name matters because the correct fix for one class is the wrong fix for another. You correct a sales mistake by editing the sales receipt, and you correct a package-quantity mistake by adjusting the package. Confuse the two and you paper over one error with another.

Correct

Correction follows the class, and a few rules survive across every METRC state because they come from the platform, not the regulator:

  • Sales errors go through the sales workflow. Edit or void the receipt. Record a return as a negative sale. Never use a package adjustment to fix a sale.
  • Quantity errors get a reason and a note. A package adjustment requires a reason code and an explanation. That is your audit trail, so write it like one.
  • Transfer errors get rejected, not absorbed. If a package arrives at the wrong quantity, reject it rather than receiving it short. Accepting it makes you liable for inventory you do not have.
  • Conversions use processing jobs only when a real category change requires new testing. Reach for a production batch by reflex and you can reset a package's test status and strip its results.

Verify

Then you do the thing almost everyone skips: you re-run the audit. Not the whole day, just the exceptions you touched. Confirm the corrected sale now carries a METRC receipt ID, the adjusted package matches the physical count, and the rejected transfer left your inventory clean. This is how you catch a correction that fixed the visible number and broke an invisible one. "Fixed" and "verified fixed" are not the same state, and the gap between them is where same-day drift lives, the discrepancy that comes back at close because nobody confirmed the correction actually took.

Catching discrepancies at the event

The daily loop catches what already drifted. It is cheaper to catch a discrepancy at the moment it happens, which is almost always a receive, a transfer, or a conversion. A short checklist at receiving prevents more problems than any amount of end-of-day reconciliation:

  • Accept the transfer in METRC first, then receive it into the POS.
  • Confirm shipped quantity before acceptance; reject mismatches rather than receiving short.
  • Verify the product mapping and unit weight before importing into the POS.
  • Avoid double-clicking receive, one click can become two manifests.
  • Pull lab data on receive if your platform supports it, to head off false "untested" flags later.

A discrepancy you prevent at receiving never enters the exception queue in the first place.

Closing note

Correction feels like the finish line because the screens agree the moment you are done. But that agreement only proves you changed something, not that you fixed the right thing. In practice the teams that stayed clean were the ones that ran verification every day, even when it felt redundant. It is the stage that gets cut first, and it is usually the one worth keeping.