Most reconciliation routines I have watched run three stages and call it four. They detect a discrepancy, they correct it, and somewhere in between they classify it, sometimes. Then they close the ticket. The stage that gets dropped is the last one, and it is the one that decides whether the fix actually held.

A reconciliation that holds runs four stages in order: detect, classify, correct, verify. The order is not decoration. Skip detection and you correct things at random. Skip classification and you apply the wrong fix. Skip correction and nothing changes. Skip verification (the easy one to skip, because the screens already agree) and you never learn that your correction created a second discrepancy somewhere else.

Detect

Detection is comparison, not inspection. You are not walking the floor looking for problems; you are lining up two exports and letting 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.

Detection produces a list, not a verdict. Its only job is to decide what gets a human's attention.

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 is mandatory because the correct fix for one class is the wrong fix for another. A sales mistake is corrected by editing the sales receipt; a package-quantity mistake is corrected by adjusting the package. Confuse the two and you paper over one error with another. Classification is the cheap step that prevents the expensive mistake.

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 the audit trail; treat it as the point of the adjustment, not a formality.
  • 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. You confirm the corrected sale now carries a METRC receipt ID, the adjusted package matches the physical count, the rejected transfer left your inventory clean. Verification is how you catch the correction that fixed the visible number and broke an invisible one. The screens agreeing is the start of verification, not the end of it.

"Fixed" and "verified fixed" are different states. The gap between them is where same-day drift lives, the discrepancy that comes back by closing because the correction was never actually confirmed.

Catch it at the event, not at the count

The daily loop catches what already drifted. Cheaper still is catching discrepancies at the moment they are born, 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 prevented at receiving never enters the exception queue at all. That is the cheapest reconciliation there is.

What I learned

The teams that stayed clean were not the ones that corrected the fastest. They were the ones that verified. Correction feels like the finish line because the screens agree the moment you are done. But agreement at the moment of the fix proves only that you changed something, not that you changed the right thing in a way that lasts. The fourth stage is unglamorous and easy to cut. It is also the only one that tells you the truth.