A discrepancy rarely costs much to fix. What it costs is the routing. A package metadata problem sits in a POS support queue for three days before someone explains the POS cannot change it. A regulatory question goes to the software vendor, who cannot answer it. The mismatch was solvable in ten minutes; the wrong first email turned it into a week.
The fastest reconciliation teams I have worked with were not better at fixing things. They were better at knowing whose problem each thing was. Once the discrepancy is named, the next question is not "how do I fix it" but "who can fix it", and there are only five answers.
The five desks
Every discrepancy resolves at one of five desks. The skill is matching the problem to the desk on the first try.
| Desk | Owns | Send it here when |
|---|---|---|
| You, in-house | Formatting, mapping, stale syncs, missing imports | The cause is a spreadsheet timestamp, a product mapping, a sync that needs refreshing, or a package never imported |
| The supplier | Package-level metadata recorded at the source | The unit weight, item, category, or lab result is wrong on the package itself, before it ever reached you |
| METRC support | The platform and its system state | The package's state blocks the normal fix: a transferred-out package, a platform or API issue, a correction the interface won't allow |
| Your regulator | Statutory and licensing questions | The question is about a rule, a license or manifest contact record, or a compliance notice whose cause is still unclear |
| POS support | The integration layer | The problem is API keys, audit tools, task queues, or a vendor-specific receive, return, or manifest flow |
The two routing mistakes
Almost every misroute is one of two errors, and both are worth naming because they are so easy to make.
The first is sending a source-data problem to a downstream desk. When a package arrives with the wrong unit weight, neither you nor your POS can correct metadata that was entered upstream. Changing your own count to match it just creates a quantity discrepancy on top of a metadata one. That ticket belongs to the supplier who recorded the package, full stop. The POS help desk can spend a day confirming what it cannot change.
The second is sending a regulatory question to a technical desk. There is a clean line worth memorizing: the platform vendor owns the technical and operational side of the tracking system, and the state owns the statutory and regulatory side. A how-do-I-record-this question is technical. A what-am-I-required-to-do question is regulatory. They go to different places, and each desk will struggle politely with the other's question before telling you that you have the wrong one.
A package that has been transferred out of your facility is the classic trap. It may no longer exist under your license, so the normal correction is simply unavailable, and that is a METRC support conversation, not a quantity you can adjust your way out of.
Fix in-house first, but only the in-house problems
The default should still be to resolve things yourself, because the largest category genuinely is yours: timestamp formatting, product mapping, stale syncs, missing imports. Reaching for support on those is slower than fixing them. The discipline is not "escalate less." It is "escalate the right things to the right desk, and keep the rest." Escalating a mapping error wastes a day. Failing to escalate a transferred-out package wastes a week, because you keep trying corrections the system will never accept.
Write the routing rule down
The reason teams misroute is that the decision lives in one experienced person's head. When that person is out, everything either stalls or goes to the wrong desk. The fix is the same one that helps everywhere else in reconciliation: write it down. A five-row table taped next to the workstation turns a judgment call into a lookup, and turns a week back into ten minutes.
What I learned
I used to think discrepancy work was about correction skill, knowing the exact sequence of clicks. More often it was about triage. The cost was almost never in the fix; it was in the days lost pointing the problem at someone who was never able to solve it. Naming the discrepancy tells you what is wrong. Naming the desk tells you who can make it right. The second question is the one that actually saves the time.