Executive Summary
This white paper looks at how Archer Insights designed license management logic inside NetSuite for two Life Sciences distributors: a multi-state pharmaceutical company handling controlled and non-controlled products, and a radiopharmaceutical organization managing radioactive material possession limits. In both cases, license terms were built as structured NetSuite records tied directly to the transactions they govern, rather than tracked separately as documents and renewal dates. This piece walks through the regulatory basis for each requirement, how the underlying license data model differed between the two businesses, and what it takes operationally to sustain that kind of control once it is built.
1. Why a Renewal Calendar Isn't Enough
Most Life Sciences companies manage drug licenses as documents: a PDF on file, a renewal date on a calendar. That works for tracking whether a license exists. It doesn't work for the question that actually matters at the moment an order is placed, which is whether that specific transaction is allowed to happen.
A mature license management model treats licenses differently. It links each license's terms, status, expiration, jurisdiction, covered product, and the specific entity, customer, location, or shipping party it governs directly to the transactions that depend on it. Instead of a document someone has to remember to check, the license becomes a condition the order itself has to satisfy before it moves forward. NetSuite is well suited to running that kind of control, and this white paper uses two license models Archer Insights has designed inside NetSuite, one for a multi-state controlled substance distributor and one for a radiopharmaceutical company, to show what that looks like in practice.
That distinction, between tracking that a license exists and confirming a transaction is authorized, is easy to state and easy to miss in practice.
Those aren't the same question. A folder of PDFs tells you a document exists. It doesn't tell you, at the moment an order is entered, whether the selling entity, the customer, the receiving location, and the carrier are all authorized for that product in that jurisdiction. A distributor operating across a dozen states can have a completely current set of licenses on file and still ship a controlled substance into a state where that particular subsidiary was never registered to sell it. The renewal date wasn't the problem. The authorization scope was.
DEA registration is a good example of why the distinction matters. Under the Controlled Substances Act, registration is tied to a specific principal place of business, and 21 CFR 1301.12(a) requires a separate registration for each location where controlled substances are manufactured, distributed, or dispensed. One federal registration does not automatically extend to every location or jurisdiction, and state requirements may impose additional licensing or registration requirements depending on the jurisdiction and activity. A renewal calendar has no way to represent that. A structured license record, built as operational data inside the transaction system rather than a document sitting next to it, does.
2. Where NetSuite Fits
That's a platform question as much as a policy one, and it's where NetSuite's architecture is genuinely well suited to the problem. NetSuite is built around structured records, related lists, and native workflow tooling (SuiteFlow, saved searches, and scripting through SuiteScript) that can evaluate conditions against a transaction before it's approved. A license doesn't have to live in a separate compliance system disconnected from order processing. It can live as a related record tied to the entity, customer, or item it governs, with fields for jurisdiction, product scope, expiration, and status, and NetSuite's workflow framework can be configured to evaluate those fields during relevant transaction processes.
That's the shift Archer designs for: taking a license from something compliance tracks off to the side and making it something the transaction engine actually reads. The configuration work varies by business, since the license attributes that matter for a wholesale pharmaceutical distributor look nothing like the ones that matter for a radiopharmaceutical company, but the underlying pattern, building license information as structured data that NetSuite workflows can evaluate, can be adapted across both use cases.
3. A Multi-State Controlled Substance Distributor
Archer designed a licensing model inside NetSuite for a pharmaceutical company distributing controlled and non-controlled products across multiple states. Nothing about the requirement sounded unusual at first. It turned out to be more layered than a typical license-tracking project.
Four separate questions had to get answered, automatically, every time an order was entered. Was the selling subsidiary authorized to sell the drug into the destination state? Did the customer hold a valid license to purchase it? Was the customer's receiving location itself licensed to receive it there? Was the applicable third-party logistics provider authorized to provide the relevant services in those jurisdictions?
Each question could land differently depending on the product, the state, and the party involved, so Archer built the license record to identify which role it applied to, seller, customer, or shipping/3PL location, with its own expiration date, status, and a flag for controlled versus non-controlled product. Using NetSuite's native customization framework, custom record types linked to entities and items, combined with SuiteFlow logic on the sales order, the system checked whatever conditions applied during order processing. If a required license was missing, expired, or otherwise invalid, the order got flagged and held for review before it could go through, all inside the same transaction the sales team was already working in rather than a separate compliance checklist.
This lines up with how the Drug Supply Chain Security Act treats trading partner status. Under Section 582 of the FD&C Act, wholesale distributors and dispensers can only transact with authorized trading partners, and part of what makes a partner "authorized" is holding a valid state license for whatever role they play in the supply chain. It's also not a one-time check at onboarding. Licensure status needs to be validated and maintained over time. FDA requires wholesale distributors and 3PLs to report licensure information annually, while trading partners need processes for confirming that applicable authorization requirements are met. That's exactly the kind of thing a static folder of documents can't represent well. A license valid on day one can lapse quietly a year later, and a lapse can go undetected until the organization reviews the transaction or a regulator requests evidence.
The interesting part of this project wasn't any single check. It was that NetSuite stopped being a place where the license sat next to the customer record as a reference document, and became the place where the license was actually enforced.
4. A Different License Problem: Radioactive Material Limits
Archer also built a licensing model in NetSuite for a radiopharmaceutical organization, and the underlying question there wasn't the same at all, which is worth saying plainly since not every licensing problem looks like the one above.
The pharmaceutical case was mostly about whether a party was authorized to sell or receive a product in the first place. The radiopharmaceutical case was about whether a specific company-and-facility combination, or a specific customer-and-receiving-location combination, was authorized to possess a defined quantity of radioactivity for a particular isotope. A license can specify authorized radionuclides, activities, uses, and locations, with possession limits or other conditions depending on the license and applicable requirements.
That matches how NRC and Agreement State medical licensing works in practice. Depending on the license and applicable requirements, authorization may specify the radionuclides, activities, uses, and locations permitted at a facility. Archer configured the NetSuite license record to carry expiration and status like any other, alongside maximum permitted activity per isotope, any group-level aggregate cap, and the specific company-location or customer-location pairing the limit applied to. When a proposed transaction would push a facility past its permitted level, whether for a single isotope or in aggregate, NetSuite's workflow logic could raise a warning requiring review or, depending on configuration, block the transaction outright, using the same underlying platform capability as the pharmaceutical example even though the license data model itself was built from scratch around a completely different regulatory concept.
This second example isn't meant to suggest radiopharmaceutical licensing is a variant of drug distribution licensing. It's a different data model, built around quantity of activity rather than authorization to transact. License management isn't one problem with one answer. What carries over between the two cases, and what makes NetSuite a strong foundation for either, is that the platform's data model and workflow engine are flexible enough to be configured around whatever the license actually needs to track, rather than forcing the business into a fixed template.
5. What It Takes to Make This Work
Getting from a document folder to license-aware transaction control inside NetSuite isn't mostly a technology problem, though the platform capability matters. A few things need to be in place first.
Someone has to own the data. Not just renewing licenses on schedule, but updating scope, jurisdiction, and product coverage when any of it changes. This usually sits with compliance or regulatory affairs, but order management needs visibility into it too, since they're the ones who'll see the exceptions NetSuite raises.
The data has to be clean. A validation rule is only as good as the record behind it. Incomplete, duplicated, or inconsistently scoped license records mean the control will either block orders that should go through, or worse, let through orders it should have caught.
A blocked order needs somewhere to go. NetSuite's workflow and approval routing can hold an order and notify the right reviewer, but someone still has to review the exception, see why it triggered, and either clear it, fix the underlying license data, or hold the transaction. Without a defined path, transaction controls just become a backlog nobody clears.
Expiration should surface early, not only at the point of failure. A license thirty days out should already be visible to whoever manages that customer or lane, and NetSuite's saved search and alerting tools can surface that on a dashboard well before an order actually gets blocked on it.
Every check, override, and exception needs a record. Auditors won't just ask whether a license was current. They'll ask whether the system was actually checking it at the time the transaction happened, and for how long that record has to hold up. DSCSA sets a real benchmark here: trading partners are required to retain transaction records for six years, a requirement spelled out for dispensers specifically at Section 582(d)(1)(A)(iii) of the FD&C Act, with parallel retention obligations for manufacturers, wholesale distributors, and repackagers elsewhere in the same section. NetSuite provides transaction audit trails and workflow history, but the retention design needs to be configured around the applicable regulatory requirements.
And the data usually doesn't originate in NetSuite to begin with. It comes from a state board portal, an internal compliance system, or a third-party verification service. Archer typically integrates that external license data into NetSuite so the record the transaction engine reads is current and trustworthy at the moment it's needed. The integration matters as much as the data model does, and it's one of the areas where configuration experience, knowing which fields NetSuite needs and how often they need to refresh, makes the difference between a control that works and one that quietly goes stale.
6. Where This Leaves Things
A distributor moving controlled substances across state lines and a radiopharmaceutical company managing isotope possession limits need different license attributes, different validation logic, different escalation rules. Neither one needs the same data model as the other, and neither should be forced into it. What they share is a starting assumption: license data isn't background information sitting near a transaction. It's a condition of the transaction, and NetSuite has the underlying flexibility, custom records, workflow logic, and approval routing, to enforce that condition without needing a separate system bolted on for the purpose.
That means moving licensing out of a compliance archive and into the transaction path itself, configured directly in the ERP the business already runs on, so the system isn't just answering whether a license exists on file. It's answering whether this specific order is allowed to happen.
This white paper describes systems design principles and operational patterns Archer Insights has encountered in Life Sciences ERP implementations. It is not legal advice, and specific licensing and regulatory requirements should be confirmed with qualified counsel and the relevant regulatory authorities, as they vary by product, jurisdiction, and business model.