Florida depends on integration quality more than most cannabis markets, because the state traceability layer is largely API-driven rather than a regulator-facing operator screen. An internal seed-to-sale system is considered fully integrated with the Department's system only when it establishes real-time connectivity through an API. There is no state-side interface where an operator can browse what was reported the way they can in some other markets.

What "no state UI" changes

When you can't log into a state screen to confirm what was reported, your only visibility comes through the integration's own tools: receipt audits, package journals, sync-level review screens, and manifest detail. In Florida those tools aren't conveniences. They are the audit surface, and a reconciliation program has to treat the vendor's audit features as primary evidence, because there is no second window onto the state record.

Two implementation details that matter

The External Package ID field

Some Florida integrations let an operator keep existing local Package IDs on physical labels while storing the BioTrack 16-digit identifier in an External Package ID field. That does two useful things: it preserves on-package labels during a migration, and it gives a workbook both the local and the state identifier to join on. Any reconciliation that crosses between shop-floor labels and state records depends on that mapping existing and being correct.

MMUR read-only after integration

At least one platform makes the MMUR read-only once the BioTrack STS integration is live, posting dispensations through BioTrack instead of through separate manual MMUR actions. Platforms do this differently, but the principle is worth copying on purpose: don't let retail teams get used to "fixing it later" in a second system. The fewer places a correction can be made by hand, the fewer ways the four surfaces can drift apart.

Behaviors to document for your deployment

  • Repost timing. A reposted receipt appears under the repost date, not the original, which creates an audit-date mismatch. Worth knowing before you re-post anything.
  • Sync-level corrections. Integration-audit corrections can be dangerous if applied without understanding the root cause first.
  • Sale-post timing. Know whether sales post in real time or on a delay, because that window is where timing discrepancies live.

A vendor due-diligence checklist

Public Florida operator documentation is stronger for some platforms than others. Where it's thin, demand documented proof, in the vendor's Florida material or approved implementation docs, of each of the following. Assume anything undocumented can become an audit blind spot:

  • Package-level identifier mapping (local ID and the 16-digit state ID)
  • Sale-post timing and real-time behavior
  • Void and refund behavior, including inventory effect
  • Manifest handling for internal transfers and delivery
  • Order and route mapping into the MMUR
  • MMUR integration method (and whether it becomes read-only)
  • Error-log location and retry logic

Where this leaves you

In an API-only state, the integration is the compliance layer. So the vendor's receipt audits and package journals are your evidence, the External Package ID mapping has to be right, and every place a correction can be hand-entered is a place the record can drift. Document how your own deployment behaves while it's quiet, not while an inspector is waiting on the answer.