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. Something solvable in ten minutes becomes a week because the first email went to the wrong place.
So once you have named the discrepancy, the next thing to work out is who can fix it, not how. There are five places that answer ends up.
The five desks
Every discrepancy resolves at one of five desks, and the whole trick is matching the problem to the right one 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 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, and changing your own count to match just stacks a quantity discrepancy on top of the metadata one. That ticket belongs to the supplier who recorded the package. The POS help desk can only spend a day confirming they cannot change it.
The second is sending a regulatory question to a technical desk. The platform vendor owns the technical and operational side of the tracking system, and the state owns the statutory and regulatory side. How do I record this is a technical question. What am I required to do is a regulatory one. Point either desk at the other's question and they will struggle politely for a while before telling you that you have the wrong one.
A package that has been transferred out of your facility is the classic trap here. It may no longer exist under your license, so the normal correction is simply unavailable. That is a METRC support conversation, not a quantity you can adjust your way out of.
Keeping the in-house work in-house
Your default should still be to fix things yourself, because the largest category genuinely is yours: timestamp formatting, product mapping, stale syncs, missing imports. Opening a support ticket for any of those is slower than just doing the work. The goal is not to escalate less overall, it is to escalate the right things 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.
Writing the routing down
Teams misroute mostly because the decision lives in one experienced person's head. When that person is out, everything either stalls or goes to the wrong desk. A five-row table taped next to the workstation turns the judgment call into a lookup, and it means whoever is covering can get the routing right without you.
Closing note
For a long time I thought discrepancy work was about correction skill, knowing the exact sequence of clicks. Most of it is triage. Figuring out whose problem something is buys back more time than being good at the fix ever does.