What Should Live in Your POS, Your ERP, and Your State Tracker
A practical guide to which data belongs in your point of sale system, which belongs in your ERP, and which belongs in your state’s track and trace system, and why mixing them up causes most compliance headaches.
If you’ve read our pieces on cannabis ERP (Enterprise Resource Planning, the system that tracks everything your business owns, spends, and produces) and on Metrc versus BioTrack, you already know these three systems exist for different reasons. What we haven’t covered yet is the practical question operators actually ask: when a new product, a new batch, or a new customer walks through the door, which system should record what, and in what order.
Get this wrong and you end up with three systems that each think they hold the truth, which is exactly how duplicate records and audit flags happen.
Start with what each system is actually for
Your point of sale system exists to move a transaction from shelf to receipt as fast as possible, then report that sale to your state tracker. Speed and compliance reporting are its whole job.
Your ERP exists to answer a slower, deeper question: what did this product actually cost to make, and where is every unit of it right now. It’s the system of record for cost, not for speed.
Your state tracker exists for one purpose only: proving to a regulator that nothing has gone missing between seed and sale. It doesn’t care about your margins. It cares about accounting for every gram.
Three different jobs. The mistake most operators make is letting one system try to do all three, usually because it’s the system that happened to launch first at their company.
The order data should actually flow
Here’s the sequence that keeps all three systems in agreement rather than fighting each other.
A new batch gets created in your ERP first. This is where its cost basis, its recipe (if it’s a manufactured product), and its internal tracking ID all get set. The ERP is the birth certificate.
That batch gets registered with your state tracker next, tagged, and given whatever identifier your jurisdiction requires. This step exists purely to satisfy the regulator, and it should happen automatically if your systems are properly connected, not as a second manual entry.
The product only touches your POS once it’s ready to sell. At that point, the POS needs exactly three things from upstream: what it is, what it costs (or at least what price to charge), and confirmation it’s legally clear to sell. Everything else, the batch history, the cost breakdown, the cultivation notes, has no business living in your POS at all.
When operators try to make their POS carry cost and batch data too, that’s usually where things start drifting out of sync, because POS systems are built to be fast, not to be a permanent archive.
The three questions worth asking before you connect anything
Where does the data actually originate? Whichever system creates a piece of information first should own it. If your ERP creates the batch ID, your POS should never be allowed to edit that ID, only display it.
What happens when two systems disagree? This will happen eventually, a sync delay, a manual override, a failed API (Application Programming Interface, the connection that lets two pieces of software talk to each other automatically) call. Decide in advance which system wins that argument. Most operators pick the state tracker as the final word, since that’s the one a regulator will actually check.
How much manual re-entry does your current setup require? If your staff are typing the same batch number into three different systems by hand, that’s not a training problem, that’s a sign your systems aren’t actually talking to each other, whatever the sales brochures claimed.
A quick way to audit your own setup
Pick one product currently in your inventory and trace it backward. Can you find its original batch record in your ERP? Does that same batch ID appear, unchanged, in your state tracker? Does your POS show that exact product without anyone having retyped its name or price separately?
If the answer is yes at every step, your systems are actually integrated, not just installed side by side. If you hit a spot where someone has to manually copy a number from one screen to another, that’s your integration gap, and it’s usually smaller and cheaper to fix than operators expect once they know exactly where to look.
The takeaway
None of this requires exotic technology. It requires deciding, on paper, which system owns which fact, before you go shopping for software. Most of the compliance headaches operators describe as “our tracking system is a mess” actually trace back to this decision never being made clearly in the first place, not to any system being poorly built.
