LineNow logoLineNow
Login
Book a Demo
MetrcOperator playbook

Metrc Adjust vs Reject: What the IL_IB_0003 Bulletin Actually Says

The Illinois IL_IB_0003 Transfers Best Practices bulletin gives a clear model for transfer variances: partial packages are not approved in Illinois; use a reason-backed Accept, Accept + Adjust, or Reject workflow and post state acknowledgement before local inventory commits.

Line Now LLC/Published /Updated /11 min read

For operators

Use this playbook to tighten the buying loop.

LineNow helps teams move from manual ordering and supplier follow-up to a connected workflow for POs, receiving, inventory, and accounting handoff.

View Compliance ProcurementSee How LineNow Works

Illinois published one of the clearest regulator-aligned Metrc receive documents: the IL_IB_0003 Transfers Best Practices bulletin. Its practical message is simple: when the physical count on an incoming transfer does not match what was shipped, accepting a partial package is not the approved path in Illinois. The safer receive model is Accept, Accept + Adjust, or Reject, with a reason attached where required.

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: model your receive around per-package Accept / Accept + Adjust / Reject, and post the Metrc outcome before the local inventory 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.

If you are evaluating software for this workflow, see LineNow's compliance procurement software. This guide explains the receive decision model that product uses.

What the bulletin actually says

The relevant guidance from IL_IB_0003, paraphrased from the bulletin:

Accepting partial packages is not an approved method in Illinois. If the received quantity differs from what was shipped, best practice is to reject the whole package or accept the whole package and then adjust down or repackage damaged items for return.

If the incoming transfer is incorrect or incomplete and needs to be rejected, use the reject workflow with a reject reason and note. If damaged units are accepted within a package, the bulletin describes receiving the package and then destroying or repackaging the damaged units.

In other words, the partial-receive checkbox should not be treated as the core operational primitive for variance. 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.

Other Metrc states can differ by rule, configuration, and inspector practice. Even outside Illinois, the IL_IB_0003 model is a useful conservative design pattern: per-package decision, reason on file, and state acknowledgement before local inventory moves.

The three legitimate per-package outcomes

For every package on an incoming manifest, the receive software should make three practical outcomes explicit:

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 routine case.

2. Accept + Adjust

Physical count differs from shipped quantity, and the package is still usable. The flow is:

  1. Receive the package at the shipped quantity (or whatever your software defaults to).
  2. Immediately Adjust the package quantity to the actual physical count.
  3. Attach the state-accepted reason and a clear note explaining the variance.
  4. 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 can let you check a partial or variance option on a receive, depending on state and workflow. It is technically functional. The reasons not to use it as the main variance primitive:

1. The Illinois bulletin says partial packages are not approved in that state. If your state has different published guidance, follow that guidance. If it does not, the Illinois model is the cleaner control model.

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: avoid making the partial flag the operator's default path. Make Accept / Accept + Adjust / Reject the visible primitives. That keeps the team on a reason-backed 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 unexpected long, it’s an Accept + Adjust with the state-supported 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 should not get 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 this control model is designed to prevent. Software should make that path unavailable, 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 control logic, different system of record. The principle — per-package decision where applicable, reason on file, state filing before local commit — should carry across regulated receiving systems, but the exact endpoint, allowed reason, and receive primitive depend on the state system.

How LineNow models this

LineNow's compliance procurement software renders the bulletin-aligned receive 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. Metrc outcomes append to the manifest doc’s extractedFields. Non-Metrc regulated receipts with variance notes write a standalone other compliance document. The variance and expected_quantity should not persist only on the inventory layer itself — the audit story lives in the doc, which survives the layer draining.

The non-Metrc states get the same control model, minus the Metrc POST. The variance note still posts to the compliance document. The receive still uses explicit outcome primitives instead of a vague partial state.

What this changes operationally

Three measurable shifts when the receive is modeled this way:

  1. Weekly Metrc reconciliation shifts from finding drift to verifying filings. If the per-package post can’t commit locally until Metrc acks, the two states are less likely to diverge.
  2. Audit response on a specific manifest is one record lookup. The compliance doc has the decisions, reasons, and Metrc responses. Less to stitch.
  3. 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 inspector question — “show me what you accepted, what you adjusted, and why, for manifest M-99812” — becomes answerable from the receive record instead of a spreadsheet-and-inbox reconstruction.

Sources checked

Related