How to Choose Alcohol Importer Software

Start with the operation, not the software list

This guide is for alcohol importer operations teams comparing software for permits and compliance, customs coordination, product records, inventory, accounting, distributor sales, and trade assets. It explains the main software categories, what each category is built to control, where responsibilities overlap, and how to run a selection process without expecting one product to solve every problem.

Alcohol importer software is not one category. An enterprise resource planning system can control purchase orders and inventory but still be a poor home for bottle photography. A compliance platform may manage registrations and filing workflows without becoming the item master used by sales. A marketplace may help buyers discover products but should not be assumed to hold the importer’s complete regulatory evidence.

The right system design usually contains several tools with explicit boundaries. The first decision is therefore not which vendor to buy. It is which records and workflows need a dependable owner.

Map the regulated work before evaluating features

Software selection should begin with the obligations and operating records the business must support. Keep legal decisions with qualified compliance professionals. A system can assign tasks, preserve evidence, and record approvals, but it cannot decide which requirements apply to a particular product or transaction without accountable human review.

TTB’s official guidance says a business importing distilled spirits, wine, or malt beverages covered by the Federal Alcohol Administration Act must obtain a Federal Basic Importer’s Permit. TTB also states that the importer must maintain and staff a business office in the United States, register as an alcohol dealer, and obtain the required Certificate of Label Approval before importation for covered products. The complete summary appears in TTB’s guidance for importing bottled alcohol beverages.

The same guidance separates several responsibilities that should remain separate in the system design:

• federal permit and alcohol dealer registration records
• product formula or laboratory review when applicable
• COLA applications and approved label evidence
• natural wine or age and origin certificates when applicable
• customs entries, duties, and federal excise taxes
• FDA facility and prior notice information
• state and local licenses, registrations, reports, and commercial requirements

Do not turn that list into a universal checklist for every item. Applicability varies by commodity, alcohol content, product formulation, package, jurisdiction, and route to market. For example, TTB’s imported wine labeling guidance distinguishes wine containing at least 7 percent alcohol by volume from wine below that threshold. It also explains that some products need formula approval before a COLA application.

FDA states that covered food facilities must register and that FDA must receive advance notice of imported food shipments. Its food facility registration and submission page also explains the biennial renewal requirement for facilities required to register. Alcohol importer teams should assign ownership for the relevant facility, supplier, and shipment evidence rather than treating FDA complete as one undifferentiated checkbox.

Customs data is another distinct layer. CBP describes the Automated Commercial Environment as the system through which the trade community reports imports and exports and the government determines admissibility. The CBP ACE overview is a useful starting point when deciding what the importer, customs broker, freight partner, and internal software each own.

Separate the six main software categories

A useful shortlist starts with categories. Products can cross category boundaries, but the buying team should still know which job each product is expected to perform.

Category	Primary job	Typical controlled records	Common boundary
Compliance management	Track licenses, registrations, filings, approvals, and deadlines	License, registration, COLA, formula, filing, jurisdiction, renewal	Does not necessarily control inventory, accounting, or creative assets
Customs and logistics coordination	Support shipment, entry, broker, freight, landed-cost, and receiving workflows	Shipment, container, entry reference, lot, charges, receipt	A broker or forwarder may control part of the official transaction record
ERP and distribution operations	Control purchasing, inventory, orders, receivables, payables, pricing, and financial reporting	Vendor, item, purchase order, warehouse stock, sales order, invoice, ledger	Product storytelling and distributor-ready assets may remain awkward
Product information and asset management	Control product facts, package records, vintages, documents, images, and publication status	Product, release, market item, asset, revision, approval	Usually not the financial ledger or customs filing system
Marketplace and distributor commerce	Publish products, support discovery, communicate availability, and accept orders	Buyer-facing catalog, pricing, availability, order, account relationship	The recipient-facing listing is not the complete internal source record
Analytics and depletion reporting	Combine sales, inventory, shipment, and distributor data for review	Distributor, SKU, territory, depletion period, inventory balance, performance measure	Output quality depends on identifier mapping and source-data quality

This separation prevents a common selection mistake: comparing products that solve different problems as if they were substitutes. An ERP and an asset workspace may both contain an SKU, but that does not mean they should own the same facts or approvals.

Decide which system owns each record

Before requesting demonstrations, create a system-of-record matrix. For each important record, name the system that creates it, the system that approves it, and the systems that consume it.

Use at least these rows:

Record	Questions to resolve
Legal entity and permit	Which system stores the current permit, amendments, responsible people, locations, and renewal evidence?
Supplier and producer	Who owns legal identity, contacts, facility references, agreements, and approved producer information?
Product	Where are brand, class or type, origin, formulation status, and stable internal identity controlled?
Release or vintage	Where are vintage-sensitive production facts, tasting information, certifications, and status controlled?
Consumer package	Where are volume, label version, bottle identifiers, closure, and current images controlled?
Shipping package	Where are case pack, case identifier, dimensions, weight, and pallet details controlled?
Market item	Where are importer SKU, distributor code, state code, market status, and availability controlled?
Approval evidence	Where are formulas, COLAs, certificates, state approvals, and reviewer decisions stored?
Shipment and receipt	Where are purchase order, broker reference, entry data, lot, landed charges, and warehouse receipt reconciled?
Trade asset	Where are technical sheets, sell sheets, bottle images, logos, rights, revisions, and audience access controlled?
Commercial transaction	Where are price, order, invoice, payment, credit, and general ledger entries controlled?
Depletion record	Which distributor report is the source, and how is its item code mapped to the importer item?

One record can appear in several systems. Ownership must still be singular at the field level. If both the ERP and a marketplace display case pack, name which one decides the value and how a correction reaches the other.

The integration direction matters. A distributor code assigned after item setup should flow back to the internal market-item record. A corrected bottle volume should flow outward from the approved package record. A buyer-facing description should not overwrite regulated identity fields merely because the marketplace copy was edited more recently.

Evaluate compliance software on evidence and applicability

A compliance product should help the team determine what work is open, why it applies, who owns it, and what evidence proves completion. A dashboard with many green status labels is not enough.

TTB’s requirements for alcohol importers state that importers must keep daily records of physical receipt and disposition under 27 CFR 27.133. The page also covers permit amendments, COLAs, possible formula approval, FDA responsibilities, and state requirements. Because the page shows a January 9, 2018 update date, use it as an official overview and confirm current procedures in the linked regulations and current agency systems.

Test whether a compliance system can represent:

• requirements that apply only to a particular product or jurisdiction
• not required, pending decision, in progress, approved, expired, and superseded as distinct states
• a deciding source and qualified owner for each applicability decision
• renewal dates, filing periods, effective dates, and event-triggered reviews
• the exact product, package, entity, location, and market covered by an approval
• supporting documents and the approved revision
• corrections, resubmissions, agency correspondence, and audit history
• exports that remain understandable outside the platform

The TTB Public COLA Registry can support public verification, but a public registry result is not the complete product record. The internal record still needs to connect the approval to the exact product and package marketed by the importer.

Sovos describes its ShipCompliant importer products as covering areas such as compliance project management, state reporting, license management, product registration, and label research. These are Sovos ShipCompliant’s own capability claims. Verify the exact modules, jurisdictions, agency connections, filing responsibilities, and implementation scope in a demonstration and contract.

Evaluate ERP software on transaction integrity

The ERP should control the commercial and financial chain from purchasing through inventory and sales. Importer-specific requirements often expose weaknesses in a generic item and warehouse model.

Ask the ERP vendor to demonstrate one real item through this sequence:

1. Create a purchase order in the supplier’s unit and currency.
2. Record freight, duty, tax, brokerage, insurance, and other approved landed-cost components.
3. Receive partial quantities into the correct warehouse and lot structure.
4. Preserve case and bottle conversions without rounding away stock.
5. Apply market-specific pricing, terms, allocations, and availability.
6. Enter a distributor order, ship it, invoice it, and post the accounting entries.
7. Process a return, breakage adjustment, credit, or correction.
8. Produce the operational and financial audit trail for the transaction.

Use your own difficult examples. Include mixed vintages, a package change, more than one warehouse, a supplier currency difference, overlapping old and new items, and distributor-specific codes. A polished demonstration using one simple domestic item will not reveal whether the data model fits importing.

Cave describes its product as an integrated system for importers and distributors covering accounting, inventory, purchasing, sales, vintage management, landed cost, depletion reporting, and state-formatted filings. Those are Cave’s vendor claims, not independent verification. Its stated positioning may make it relevant to a smaller importer-distributor seeking an industry-specific back office, but the buyer should test every critical workflow and integration.

Western Computer describes 365WineTrade as an industry-specific product built on Microsoft Dynamics 365 Business Central. The vendor claims support for finance, inventory, compliance, reporting, pricing, COLA tracking, gallonage calculations, and container import management. Review the 365WineTrade product description as vendor-supplied information, then determine which functions are standard, configured, integrated, or custom for the proposed implementation.

Do not select an ERP from a feature checklist alone. Implementation ownership, data migration, accounting controls, integration maintenance, user permissions, support responsibilities, and the cost of future changes can matter as much as the module list.

Evaluate product and asset software on exact relationships

Importer teams often keep product facts in the ERP, bottle shots in shared drives, technical sheets in email, and current sell sheets in a distributor portal. The failure appears when those locations disagree.

A product and asset workspace should distinguish:

• producer or supplier
• continuing brand or product
• vintage, batch, or release
• consumer package
• shipping package
• market-specific sellable item
• compliance evidence
• technical sheet
• sell sheet
• bottle, label, logo, and lifestyle assets
• published distributor collection

The distinction is operational. A new vintage may change technical facts while retaining a continuing product identity. A bottle-size change can create a new package without changing every piece of brand copy. A distributor item code belongs to the market relationship, not to the universal product identity.

Test the correction path. Change one controlled value, such as alcohol content, case pack, or vintage, and ask the vendor to show every affected record and published asset. Then replace a sell sheet. The old revision should leave current distributor access without losing its history, source, or approval record.

Depletement is a pre-launch workspace for alcohol importer operations teams. It is being designed to organize product and catalog information, bottle and brand assets, technical sheets, sell sheets, distributor asset access, and vintage updates. That makes it relevant to the product-information and trade-asset layer described here. Since it is pre-launch, evaluate those as planned capabilities rather than features available today, and do not assume it replaces an ERP, customs broker system, or compliance filing platform.

Evaluate marketplaces as publication and transaction channels

A marketplace can help a distributor or account discover products, see pricing and availability, communicate with a representative, and place an order. Those jobs are valuable, but they are downstream from controlled product, inventory, account, and pricing records.

SevenFifty says that it joined with Provi in 2022 and describes the combined offering as a marketplace connecting beverage alcohol buyers, distributors, importers, producers, and brand managers. Its page for importers and producers focuses on buyer discovery and online purchasing. Treat the audience and product-count figures on that page as vendor-reported marketing claims.

For any marketplace integration, test these cases:

• a new item without a distributor code
• two vintages active at the same time
• one product sold in several package sizes
• an out-of-stock or allocated item
• a price or deal limited to specific accounts
• an item rename that should not create a duplicate
• an order containing a discontinued code
• an integration outage followed by recovery
• a corrected description or image that must replace an older version

The importer should be able to explain where each marketplace field originates and how discrepancies are resolved. Manual edits made only in the channel create another unofficial source.

Review integrations as controlled workflows

An integration diagram with arrows is not evidence that the workflow is reliable. For each connection, document the record, direction, trigger, frequency, transformation, error owner, and reconciliation method.

Use an integration register like this:

Connection	Required decision
Product workspace to ERP	Which approved identity and package fields flow into item setup?
ERP to marketplace	Which items, prices, inventory states, and account rules are published?
Marketplace to ERP	When does an order become an accepted sales order, and how are failures handled?
Broker or logistics source to ERP	Which entry, shipment, lot, charge, and receipt data are imported?
Compliance platform to product record	How are approval status and exact evidence associated with the marketed package?
Distributor report to analytics	How are distributor codes mapped, exceptions reviewed, and restatements preserved?
Product workspace to distributor portal	Which approved assets become current, and how are predecessors retired?

Require a visible exception queue. Silent failures are dangerous because the destination can look complete while holding stale data. The responsible operator should see the failed record, reason, source value, destination value, retry history, and correction action.

Also decide what happens when an integration is unavailable. A documented temporary process should preserve stable identifiers and make later reconciliation possible. Re-entering data without source references can create duplicates that are hard to unwind.

Compare vendors with scenarios, not adjectives

Replace broad questions such as Does the system handle compliance? with demonstrations based on your records. Give each vendor the same scenarios and score the observable result.

A useful evaluation set includes:

Product launch

Create one imported product with a supplier, formula decision when applicable, COLA evidence, consumer package, case pack, importer SKU, initial purchase order, market assignment, bottle image, technical sheet, and distributor-ready collection.

Vintage or package transition

Create a successor while the prior item remains sellable. Show which values carry forward, which require review, how codes differ, and how both items remain clear to operations and distributors.

Shipment and landed cost

Receive a partial international shipment with several approved charge types. Show the source documents, allocations, warehouse receipt, inventory valuation, and reconciliation.

Compliance renewal or amendment

Change a regulated business detail or approach a renewal. Show the responsible owner, due date, source requirement, filing evidence, approval, and audit history.

Distributor order and depletion

Publish an item, accept an order, invoice it, then ingest a distributor depletion record using the distributor’s item code. Show the mapping back to the internal item.

Published correction

Correct a controlled fact that appears in a product page and sell sheet. Show source approval, impact identification, replacement publication, old-revision retirement, and recipient notification.

Score each scenario against agreed criteria:

Criterion	What to observe
Data model fit	Does the system represent the real entities without overloaded fields or duplicate records?
Control	Are ownership, approval, status, evidence, and revision history explicit?
Usability	Can the responsible operator complete the task without hidden administrator intervention?
Integration	Are mappings, exceptions, retries, and reconciliation visible?
Reporting	Can users trace an output back to the underlying records?
Permissions	Can duties and audiences be separated at the needed level?
Portability	Can the business export useful records and files with stable identifiers?
Implementation	Are migration, configuration, testing, training, and support responsibilities clear?

Record gaps as gaps. Do not convert planned, available through a partner, possible with customization, and included now into the same checkmark.

Inspect security, access, and continuity

Importer software can contain commercial terms, customer information, supplier documents, regulated records, banking details, pricing, and unpublished product material. Ask vendors for documentation that lets the responsible technical and legal reviewers evaluate the proposed service.

Cover at least:

• role-based access and separation of administrative privileges
• multifactor authentication and single sign-on options
• audit logs for access, edits, approvals, exports, and permission changes
• data encryption and backup practices
• incident response and customer notification terms
• subprocessor and hosting information
• data retention, deletion, and account-closure procedures
• export formats for records, attachments, relationships, and history
• recovery objectives and tested continuity procedures
• ownership of custom configurations and integrations

Then test ordinary permission cases. A distributor user should not reach supplier contracts. A sales contributor should not approve a regulated field merely because that person can edit product copy. A former employee should lose access across the full stack, not only in the email account.

Plan migration around decisions, not file copying

Migration is where ambiguous legacy records become visible. Do not import every spreadsheet column and folder into a new structure before deciding what the records mean.

Use this sequence:

1. Inventory systems, spreadsheets, folders, interfaces, and recurring reports.
2. Identify stable entities and assign internal IDs.
3. Name the deciding source and owner for each field group.
4. Separate current, historical, draft, superseded, restricted, and unknown material.
5. Resolve duplicate products and conflicting identifiers.
6. Preserve source references and prior revisions.
7. Migrate one representative portfolio slice.
8. Run the selection scenarios against migrated records.
9. Reconcile counts, balances, approvals, files, and relationships.
10. Expand only after owners accept the results.

Choose a pilot with real complexity. One supplier, several products, overlapping vintages, more than one package size, an active shipment, a distributor code, and a published correction will reveal more than a large set of clean sample rows.

Do not treat unexplained blanks as valid migration values. Distinguish unknown, not provided, pending review, not applicable, and intentionally withheld. Each state requires a different next action.

Build the final software decision from explicit boundaries

The final recommendation should describe a target operating model, not just a winning vendor. State which system owns each record, which integrations are required, which manual reviews remain, and which tools will be retired.

A concise decision package should contain:

• business problems and measurable acceptance criteria
• in-scope entities, markets, users, and workflows
• current and target system-of-record matrices
• required scenarios and scored results
• verified capabilities, configuration needs, custom work, and known gaps
• integration contracts and exception ownership
• data migration and reconciliation plan
• security, legal, and continuity review outcomes
• implementation roles, stages, and acceptance gates
• ongoing administration and change-control responsibilities
• exit and data-export plan

The important outcome is operational clarity. A team member should know where to update a case pack, where to find the approved label evidence, which system publishes the distributor asset, and who resolves a failed order sync.

Complete the alcohol importer software checklist

Use this checklist before signing a contract or starting implementation.

Scope and ownership

• Every required workflow has a named owner.
• Product, release, package, market item, approval, shipment, asset, transaction, and depletion records are defined.
• Each critical field has one deciding source.
• Regulatory applicability decisions remain with qualified owners.
• The proposed software categories and boundaries are explicit.

Compliance and evidence

• Permit, registration, amendment, renewal, and discontinuance workflows are covered where applicable.
• Formula, laboratory review, COLA, certificate, FDA, customs, state, and local records remain distinct.
• Approvals connect to the exact entity, product, package, and market they cover.
• Daily receipt and disposition record needs have been mapped.
• Evidence, correspondence, corrections, and prior revisions remain retrievable.

ERP and logistics

• Purchasing, currency, landed cost, partial receipt, inventory, sales, returns, and accounting were demonstrated with company data.
• Cases, bottles, lots, vintages, and warehouses reconcile.
• Pricing, allocations, terms, and availability can be scoped correctly.
• Customs broker and freight responsibilities are documented.
• Operational reports reconcile to transactions and the financial ledger.

Product data and trade assets

• Product, vintage or release, consumer package, shipping package, and market item are separate but linked.
• Bottle images, labels, technical sheets, sell sheets, and logos have owner, status, revision, and audience metadata.
• A field correction produces an impact list across published outputs.
• A replacement asset retires its predecessor without deleting history.
• Distributor access excludes drafts, restricted evidence, and unrelated markets.

Marketplace and analytics

• Product, price, inventory, account, and order ownership is clear.
• New items, overlapping vintages, package variants, allocations, and discontinued codes were tested.
• Distributor codes map back to stable internal items.
• Depletion restatements and unmapped rows have a review process.
• Vendor metrics and capability claims are treated as vendor claims until verified.

Integration and implementation

• Every interface has a direction, trigger, mapping, frequency, and owner.
• Failures appear in a visible exception queue.
• Retry and reconciliation procedures were tested.
• Migration preserves stable IDs, sources, approvals, relationships, and history.
• Training and acceptance use real operating scenarios.
• Data export and service-exit procedures are documented.

Alcohol importer software works when each system has a precise job and the handoffs are controlled. Choose the smallest stack that can preserve regulated evidence, transaction integrity, exact product relationships, and dependable distributor outputs. Then prove it with your hardest ordinary work before committing the full portfolio.