Metrc Adjust vs Reject: What the IL_IB_0003 Bulletin Actually Says
The Illinois IL_IB_0003 Transfers Best Practices bulletin is the only published Metrc-aligned regulator guidance on the question of how to handle a transfer where the physical count does not match shipped quantity. The answer: do not use the partial-receive checkbox — use Reject or Adjust. This guide walks the three legitimate per-package outcomes (Accept / Accept + Adjust / Reject), the strict-acknowledgement rule that prevents POS-vs-Metrc drift, the decision tree between Adjust and Reject, and how a software-level receive flow should model the bulletin by default.There is a single page from Illinois that quietly defines how every Metrc receive should be modeled. It is the IL_IB_0003 Transfers Best Practices bulletin, and the rule it lays down is simple: when a package on an incoming Metrc transfer does not match what was shipped, you do not use the partial-receive checkbox — you use Reject or Adjust. Despite being a one-state bulletin, every Metrc-state operator’s receive should respect it, because it is the only documented Metrc position on the question, and every state inspector reads the same playbook.
This guide is for the dispensary owner, compliance manager, or operations lead trying to answer: when do I Adjust, when do I Reject, when do I post the partial flag, and how do I keep my POS receipt and my Metrc filing from drifting?
The short version: ignore the partial flag, model your receive around per-package Accept / Adjust / Reject, and post to Metrc the local commit. The long version is below.
If you have ever opened your weekly Metrc reconciliation report and found a 14-unit drift between your POS and the state, this is for you.
What the bulletin actually says
Two relevant lines from IL_IB_0003 (paraphrased — read the original from the IDFPR Adult Use Cannabis program for the canonical text):
Licensees should not use the partial receipt option on incoming transfers. When the physical count does not match the shipped quantity, the correct procedure is to receive the package and then adjust the quantity, or to reject the package back to the shipping licensee.
Damaged-in-transfer packages should be rejected, not received and then disposed of.
In other words, Metrc itself offers a “partial receive” feature, and the regulator is telling you not to use it. The reason is structural: a partial-receive event is ambiguous from the state’s perspective — was the missing weight diverted, mislabeled, stolen, lost in transit, or never shipped? Adjust and Reject force the operator to attest to which, with a reason on file. Partial does not.
A handful of states (most other Metrc states without a published bulletin) have informally adopted the same posture. So: even if you’re not in Illinois, the safest receive flow is the one IL_IB_0003 describes.
The three legitimate per-package outcomes
For every package on an incoming manifest, there are exactly three approved decisions:
1. Accept
Physical count matches shipped quantity. The package becomes received inventory on your license at the shipped quantity. No Adjust, no Reject. This is the boring 95% of receives.
2. Accept + Adjust
Physical count differs from shipped quantity, and the package is still usable. The flow is:
- Receive the package at the shipped quantity (or whatever your software defaults to).
- Immediately Adjust the package quantity to the actual physical count.
- Attach a reason — the categories Metrc accepts are typically: Damage, Theft (yes really), Mandatory State Destruction, Internal QA Sample, Spoilage, and a few others depending on state.
- Free-text note explaining the specifics.
The Adjust call is what the state files. If you accept at shipped quantity and never Adjust, your POS will drain less stock than Metrc shows you have, and the drift accumulates until reconciliation finds it.
3. Reject
The entire package is unusable. Damaged seal, contamination, wrong item received, item not on the manifest. The shipped quantity returns to the shipping license. Nothing lands on yours. A reject reason gets posted.
A common mistake: accepting a damaged package and then trying to do a Mandatory Destruction Adjustment locally. That is the right shape for an internal disposal after you owned the package — not for damaged-in-transfer. Damaged-in-transfer is a Reject so the shipper bears the loss and can pursue it with their carrier or their cultivator.
Why the partial-receive checkbox is the wrong primitive
The Metrc UI lets you check “Partial” on a receive, which marks the transfer as received-with-some-packages-pending. It’s technically functional. The reasons not to use it:
1. The bulletin says don’t. Whatever your state, the only published Metrc-aligned regulator guidance on the question says use Reject/Adjust.
2. It leaves the transfer in a non-terminal state. A partial receive means the transfer is open until the remaining packages are either received or rejected later. The shipping licensee’s books stay in a pending state too. That ambiguity is operationally awkward and audit-uncomfortable.
3. It hides the reason. Partial-receive doesn’t require you to declare why the partial happened. Adjust and Reject do. The reason is what makes the decision audit-defensible.
4. It encourages local drift. When a transfer stays partially open in Metrc, operators tend to receive the rest into their POS to keep selling — and the POS state diverges from Metrc until someone catches up.
The right software-level posture is: don’t even surface the partial flag. Make Accept / Accept + Adjust / Reject the only available primitives. That keeps the team on the bulletin-aligned path without having to remember the bulletin every time.
Adjust vs Reject: a quick decision tree
If you can answer “yes” to any of these, it’s a Reject:
- Was the package damaged before you took physical possession?
- Was the package’s seal broken or tampered with on arrival?
- Was the item different from what the manifest says?
- Was the package never physically present on the truck?
If the package is usable and the variance is just a quantity short (or, rarely, an unexpected long), it’s an Accept + Adjust with the Damage / Theft / Spoilage / Mandatory State Destruction / Internal QA Sample reason that fits.
If everything matches, it’s an Accept, and you do not touch Adjust or Reject.
The one nuance: if a small portion of a package is unusable but the rest is fine, the right flow is to Accept the package at shipped quantity and then run a separate local Adjust against the unusable portion with the appropriate destruction reason. The damaged units are on your license now (because you accepted the package), so Reject is no longer available — disposal is.
The strict-acknowledgement rule
Every per-package decision should be POSTed to Metrc before the local inventory write commits. This is the operational rule that prevents drift, and it’s how Adjust/Reject was designed to be modeled.
Two consequences:
1. If Metrc fails, the local receive aborts. The buyer sees the exact Metrc error and fixes it before retrying. Maybe the manifest was already closed. Maybe the receiver license was wrong. Whatever it is, the local inventory state never gets ahead of the state-of-record.
2. Adjust reasons stop drifting. When the variance note lives in the receive form and posts as the Metrc Adjust reason in the same transaction, the two records can’t diverge. The version of the reason your buyer typed is the version Metrc has on file.
The wrong shape — “commit locally first, file with Metrc later, reconcile drift weekly” — is exactly the pattern the bulletin was written to prevent. Software should make it impossible, not optional.
Common operator questions
What if the manifest is wrong but the package is fine?
Manifest says 100g, physical is 100g, but the manifest lists the wrong item type or wrong category. That’s technically a shipper data-entry error, not a quantity variance. The clean path is to Reject the package, contact the shipper, and have them re-create the manifest with the correct item. Accepting and then Adjusting the category inside Metrc is not always permitted and can fail validation.
Can I Adjust the package after the receive transaction closes?
Yes, but you lose the per-receive audit story. The Adjust will show up as a standalone event in Metrc, not as part of the receive. Operationally that’s fine for in-house disposals later, but for variances that exist at receive time, post the Adjust within the receive transaction.
What about over-counts (physical count higher than shipped)?
Rare but it happens. Accept at shipped, then Adjust up with a reason. Some states treat unexplained over-counts as a flag; the reason is what avoids that.
What reason should I use for damaged-but-still-attached-to-the-shipment?
If the damage occurred in transit and you’re refusing the package — Reject with a damage reason. If you’re keeping the package because most of it is fine — Accept, then Adjust the unusable portion with Damage or Mandatory State Destruction (whichever your state accepts), with a free-text note.
Does this apply to non-Metrc states?
Same logic, different system of record. Massachusetts uses LeafLogix MJ Platform, Washington uses LCB Traceability (formerly MJ Freeway). The principle — per-package decision, reason on file, state filing before local commit — applies the same way. Your software just posts to a different endpoint.
How LineNow models this
LineNow’s Receive dialog renders the bulletin-aligned shape by default:
- No partial flag. It’s deliberately not in the UI.
- Symmetric Shipped + Adjustment + Net received UX on every regulated lot. State-pulled lots lock Shipped (you can’t edit what came from Metrc); buyer-managed lots make Shipped editable. Adjustment is disabled until Shipped is entered.
- Reject package + Undo reject on every regulated lot row. Reject stashes the prior quantity (we don’t infer from
qty == 0, which loses the prior shipped quantity on undo). - Per-package decisions POST to Metrc first. If any one fails, the entire receive aborts and the buyer sees the Metrc error.
- Adjust reason flows to the Metrc Adjust call as the structured reason. The buyer types it once.
- Compliance document audit. Every Metrc outcome appends to the manifest doc’s
extractedFields. Non-Metrc regulated receipts with variance notes write a standaloneothercompliance document. The variance and expected_quantity never persist on the inventory layer itself — the audit story lives in the doc, which survives the layer draining.
The non-Metrc states get the same UX, minus the Metrc POST. The variance note still posts to the compliance document. The receive still uses Accept / Adjust / Reject as the primitives.
What this changes operationally
Three measurable shifts when the receive is modeled this way:
- Weekly Metrc reconciliation goes from “find the drift” to “verify zero drift.” If the per-package post can’t commit locally until Metrc acks, the two states stay aligned by construction.
- Audit response on a specific manifest is one query. The compliance doc has every decision, every reason, every Metrc response. Nothing to stitch.
- The damaged-in-transfer category stops being a gray zone. Reject is the answer for damaged-on-arrival; the package goes back to the shipper’s license, the shipper pursues the carrier, your books stay clean.
The state inspector’s favorite question — “show me what you accepted, what you adjusted, and why, for manifest M-99812” — becomes answerable in seconds, not afternoons.