Cannabis Dispensary Software: Fixing METRC, Limits, and the Reconciliation Tax

Why dispensary software makes or breaks a multi-location operator

Every other retailer in America gets to treat their point of sale as plumbing. You do not. Your POS is the thing that talks to METRC, and METRC is the thing that decides whether your license survives the next inspection. A grocery chain that miscounts a case of soup writes off shrink and moves on. If your on-hand for package 1A4060300003B01000001234 says 112 grams and METRC says 118.7, that is a reportable variance and somebody has to explain it in writing.

So the stack ends up looking like this: Dutchie POS or Flowhub or Treez or BLAZE or Cova on the counter, Dutchie Ecommerce or Jane on the website, Weedmaps and Leafly pulling menus, Alpine IQ or springbig running loyalty and texts, LeafLink or Distru on the wholesale side, Onfleet or a spreadsheet for delivery, Aeropay or Dutchie Pay or CanPay for anything that is not cash, QuickBooks at the end of the month, and METRC underneath all of it refusing to be wrong. Six vendors, six sync jobs, six support queues, and not one system that holds the truth.

Here is the scene we walk into on almost every discovery call. Sunday, 11pm. The inventory manager has the METRC Active Packages export on one monitor and the POS on-hand report on the other, joined on tag number in Excel. Forty rows disagree. Most are deli jars: a gram here, 2.7 grams there, the accumulated tare drift of 400 hand-weighed eighths. Two rows are worse: sales receipts the POS believes it sent on Friday that METRC never accepted, because the API threw rate-limit errors during the after-work rush and the retry queue gave up without telling anyone. In our engagements, operators at this stage are typically burning 15 to 25 hours a week of skilled labor on reconciliation, per state, forever.

METRC sync is fire-and-forget, and the failures are silent

Off-the-shelf POS platforms post sales receipts to METRC in a background job. When the state API is slow, rate limits you, or rejects a receipt because a package was finished five minutes earlier at your other register, most of them log it and move on. You discover it three weeks later during a monthly true-up, when the fix requires a package adjustment with a reason code and a story you no longer remember.

The vendors cannot fix this for you, because their queue is shared across thousands of licensees and their support tier will not reprocess your specific Friday. A custom build treats METRC as an unreliable downstream system on purpose: a durable outbox with idempotency keys per receipt, exponential backoff, and a human-facing exception queue that a compliance manager works like an inbox, with the original cart, the budtender, the register and the timestamp attached to every failed row. On top of that, a nightly reconciliation job pulls Active Packages from METRC, diffs quantity by tag against your ledger, and emails a variance report ranked by dollar value, grouped by store, room and budtender, before anyone opens Excel. Operators who ship this stop reconciling and start reviewing. That is the whole difference.

Purchase limits break the moment a customer visits two of your stores

The limits are per person per day, not per transaction, in most markets, and they are expressed in equivalency, not units. California adult use is 28.5 grams of flower and 8 grams of concentrate. Illinois gives residents 30 grams of flower and 5 grams of concentrate and cuts that in half for non-residents. Colorado runs a one-ounce flower equivalency where an edible eats into the same bucket. Now: a customer buys 28 grams at your Michigan Ave store at noon and 14 more at your Wicker Park store at 6pm. Your POS enforced the cart, not the person, and not the day, and not across stores.

Dutchie and Flowhub check the cart in front of them. They do not run a cross-location identity ledger, because most of their customers are single-store and the feature would create liability. A custom build resolves identity at the door: the ID scan produces a hashed key (never the raw document, never in a URL), and every store writes to one rolling daily equivalency ledger. The budtender sees remaining headroom in grams-equivalent before the item hits the cart, medical cards carry their own limit profile with expiry dates, and the rules live in a versioned policy table with effective dates so an operations lead can change Illinois on the day the rule changes without a deploy. Every check is logged, so when the state asks how you enforce, you show them the ledger instead of a policy PDF.

Your menu lies, and the oversells land on the budtender

Dutchie Ecommerce, Jane, Weedmaps and Leafly all pull inventory on a schedule. Between syncs your last two Blue Dream carts sell in-store, and three online orders come in for them. Now the pickup counter tells three customers no, and one of them writes the review. The real culprit is that nobody reserves anything: on-hand is a number that gets pushed outward every few minutes instead of a balance with holds against it.

The custom answer is boring and it works: one inventory service, on-hand minus reserved equals available, reservations created at cart with a TTL, released on abandonment, and every channel reading the same available number over an event stream instead of a batch. Per-channel pricing and per-channel availability become configuration, not four separate content jobs. This is also where AI earns its place rather than decorating a slide: an after-hours SMS and web assistant that answers "do you have anything under $30 that is not a hybrid" against live availability and places a hold, and a demand forecast trained on your own sales by batch, weekday, weather and promo history that tells the purchasing manager on Monday which SKUs go out of stock by Thursday and which flower is about to age past the point where you can sell it at full price. Forecasting on flower is the highest dollar-per-line-of-code work in this category, because your product loses value on a clock.

Deli jars, batches, and the margin nobody can see

Hand-weighed flower is where the money quietly leaves. An NTEP-certified scale, a tare that drifts, a budtender rounding in the customer's favor at the end of a shift, and a jar that was already 3 grams light when it arrived from the distributor. Generic POS inventory has no concept of the weigh event, so the variance is invisible until the jar closes out.

A custom build captures the weigh itself: scale integration writes gross, tare and net per transaction, tied to the register, the budtender and the jar's tag. Variance per jar per shift becomes a report, and a 4% overpour pattern on one employee shows up in week one instead of quarter three. Receiving gets the same treatment. Vendor manifests and certificates of analysis arrive as PDFs, and document extraction is genuinely good at this now: parse the COA into batch, potency, terpene profile and test date, parse the invoice into line items and unit costs, and match both against the METRC incoming transfer before anyone types a number. That matters beyond convenience, because under 280E your cost of goods sold is the only deduction you get, so line-level costing accuracy is not accounting hygiene, it is your tax bill.

Cash, PIN debit, and a tax stack the incumbents get wrong

You take cash, PIN debit, ACH through Aeropay or Dutchie Pay, and sometimes CanPay, and you round to the dollar because nobody wants to count coins. Then the tax stack: state excise, local cannabis gross receipts, local sales tax, and a discount that has to apply before or after excise depending on the jurisdiction. Multi-jurisdiction operators find out their POS applies the promo in the wrong order only when the city auditor recalculates a quarter.

Off-the-shelf tax engines in this category are configuration screens with a handful of toggles. A custom tax engine is a rules table with jurisdiction, effective date, base, ordering and rounding, plus a recalculation harness that replays last quarter's receipts against a proposed rule change so you know the exposure before you flip it. On the cash side, drawer events (open, drop, count, close) get their own audit trail with variance by till and shift, tied to shift boundaries, so a $400 short traces to a person and a 12-minute window instead of a shrug.

What this costs and how long it takes

Digital Heroes delivery experience across 2,000+ projects: a focused first release, meaning one state, POS plus METRC integration with the outbox and reconciliation, purchase limits, and inventory as the source of truth, lands at $60k to $130k and ships in 12 to 16 weeks. A full platform with ecommerce, delivery manifests, purchasing and receiving, loyalty, payments and BI (Business Intelligence) runs $150k to $400k phased over 6 to 12 months.

What drives the number up in this category specifically: every additional traceability system beyond METRC (BioTrack in some markets, Leaf Data Systems in Washington) is effectively a new integration, not a config flag. Offline mode at the register, which you need if your stores lose internet and cannot legally stop selling, adds meaningful engineering because conflict resolution against a state ledger is genuinely hard. Delivery adds manifests, drivers, vehicles and route state. Payments adds a processor per rail. Hardware adds label printers, scales and cash drawers, each with its own driver. And migrating three years of sales history off Dutchie or Flowhub, with the tags intact so historical audits still resolve, is usually a two to three week workstream by itself.

Build versus buy, and I will take a position

Buy the off-the-shelf tool if you run one to three stores in one state, sell packaged product and prepackaged eighths, do no delivery, and your revenue is under roughly $6M. Dutchie, Flowhub, Treez and Cova are real products built by people who understand this industry, and at that size the per-store SaaS fee is cheaper than an engineer. Anyone who tells you to build at three stores is selling you something.

Build when these signals stack up: five or more locations or a second state, more than one full-time person on reconciliation, deli-style weighing at volume, a delivery operation, or vertical integration where cultivation and manufacturing and retail all touch the same packages and the seams are where your inventory dies. The clearest signal is roadmap: you have asked your vendor for cross-store limit enforcement or a real exception queue, they said it is on the roadmap, and it has been on the roadmap for four quarters. At that point you are paying a subscription to wait.

How to choose a developer for cannabis dispensary software

Four things to test, and they will separate the field fast.

• Make them draw the data model on the call. Ask how packages, items, batches, lots and SKUs relate, and where the tag lives. If they conflate a METRC package with a SKU, they have never shipped this. That single mistake costs a rebuild.
• Ask what they do when METRC returns an error at 6pm on a Friday. The right answer includes idempotency keys, an outbox, backoff and a human exception queue. The wrong answer is "we retry."
• Ask which integrations they have actually shipped, not which they have read the docs for. METRC, BioTrack, Jane, Weedmaps, Alpine IQ, Aeropay, LeafLink. Ask for the specific state and the specific year, because these APIs change.
• Ask who owns the code and where the rules live. You should own the repository outright, and jurisdiction rules, limits and tax should sit in versioned data your compliance lead can edit, not in a developer's if-statement. If a rule change requires a sprint, you bought a liability.

The operator who wins this decision is the one who stops asking "which POS is best" and starts asking "which parts of my operation can nobody else's software ever know about." Those parts are your build. Everything else, keep buying.