The short answer: for every shared field, the system that creates the record and is accountable for it should own it; the other system should hold a read-only copy plus a cross-reference ID. Before you connect a distributor management system (DMS) to an ERP, write that ownership down for each order field. Without it, the integration can work technically and still fail operationally, because two teams will look at the same order and see two different answers.
The symptom is familiar. Field sales says the order is confirmed because the DMS says so. The ERP shows it on credit hold. The warehouse pick list shows neither. Someone telephones someone else, the transaction slips a day, and month-end reconciliation becomes an argument about whose number is right.
That is not a people problem. It is an unresolved ownership decision that becomes visible once two systems exchange data. This checklist is for channel operations, order management and inventory teams at consumer goods brands evaluating a DMS that must exchange data with an existing ERP.
Why the DMS and ERP boundary is genuinely ambiguous
The boundary is ambiguous because a DMS and an ERP overlap on transactions, stock, pricing and credit. A DMS normally covers distributor-facing collaboration and downstream channel information: who bought what, from which outlet, against which stock and which agreed terms. An ERP covers broader enterprise processes, typically including finance, procurement and statutory reporting. The overlap sits exactly where distribution hurts: the same fields of transactions, stock, pricing and credit.
Because the split depends on the products you choose, there is no universal rule that a DMS replaces an ERP, or that an ERP cannot handle distribution. Treat every boundary as a local decision. Start from the operating process—order capture, validation, stock review, fulfillment, delivery and reconciliation—and ask which system holds the authoritative value at each step. That framing turns a vague integration conversation into field-level decisions you can document and test.
Five order ownership decisions to settle in writing
Write these down before the first test message, with a named owner for each decision.
- Customer and outlet identifiers. Decide which system creates an outlet record, which one holds the cross-reference ID used by the other, and who may merge or deactivate duplicates. In distributor-led markets the outlet often originates in the field while finance needs a stable customer code for invoicing; without a maintained mapping, the same shop becomes two records and two balances.
- Product, SKU and unit identity. Agree the product code structure, the pack hierarchy and the unit each system counts in. Cases-to-pieces conversion is a common source of discrepancy when one side stores transactions in cases and the other reserves stock in pieces.
- Prices, trade terms and versions. State which system owns list price and validity dates, which owns customer-specific or promotion prices, and who approves a change. Then define what happens to a transaction already captured when a price changes mid-flight, and how an approved promotion version is frozen so finance and sales argue about the same document.
- Stock position and update timing. Name the system that holds physical stock by warehouse or location, the refresh interval it feeds to the DMS, and what the screen displays when the data is stale. Inventory accuracy is a data-freshness question as much as a counting question.
- Order status, failures and access. Define each status by the action it permits, not by its label. Then name the person who monitors failed messages, who may resend, who may override a hold, and who may change master data. Record the audit trail you expect.
An example source-of-truth matrix
The table below is an illustrative set of conventions, not an industry standard. Copy it into a document, fill in the right-hand column with your own names and confirm it with both IT and operations before the first test message.
| Data element | Practical default owner | What the other system holds | Decision to record |
|---|---|---|---|
| Outlet / customer master | Whichever system creates the record first | Read-only copy plus cross-reference ID | Who may create, merge and deactivate |
| Product, SKU and units | ERP | Product code and pack mapping | Which unit each system counts in |
| List price and validity dates | ERP | The effective price for the requested date | Who approves changes; effect on open transactions |
| Customer and promotion terms | DMS or trade promotion process | Approved reference used for claims | How a version is frozen and referenced |
| Stock on hand by location | Warehouse or ERP | Labeled snapshot with timestamp | Refresh interval and stale-data display |
| Order header and status | System where the order is captured, until handoff | Mapped status code | The exact moment ownership transfers |
| Delivery and goods receipt | ERP or warehouse system | Status only | Who closes the transaction and triggers invoicing |
| Returns and credit notes | ERP | Linked return reference | How a return is matched to the original transaction and stock |
| Credit limit and hold | ERP | A hold flag on the order | Whether the DMS may accept orders for held accounts |
How failed messages, stale stock and reconciliation are handled
Exceptions should be owned, visible and recoverable before go-live, not after the first month-end. A failed message needs an owner, a visible queue, a retry rule and a safeguard that prevents the same transaction being created twice on resend. A price change needs a stated rule for transactions already in progress. A stock figure needs a timestamp the sales rep can see, so nobody commits to a delivery based on yesterday’s number.
Reconciliation is the control that proves the design works. Pick a defined period and defined source systems, then compare transaction completeness, stock-data freshness, exception volume and delivery-status visibility. A pilot that only demonstrates a happy-path transaction transfer tells you very little about whether the two systems agree when something goes wrong.
Demo questions about interfaces that actually exist
Ask these in the demonstration and get the answers written into the scope document:
- Which interfaces exist today, in which direction, and which fields do they carry?
- What happens to an order edited in the ERP while it is still open in the DMS?
- How are failed messages surfaced, retried and escalated—and who monitors the queue?
- Where can we see the last successful exchange time and record counts per batch?
- How is a return linked back to the original order and to stock?
- What audit trail exists for master-data and price changes?
- Which items are in the standard scope, and which are a separate project with separate ownership?
Where Airpalm fits in this evaluation
Airpalm describes mobile visits, route planning, store audits, sales orders, inventory and promotion management (airpalm.com, checked 9 October 2026). For a DMS–ERP conversation, the practical value of that scope depends on the ownership decisions above: which system creates the sales transaction, which one holds the price version, and which one closes the loop after delivery. Whether a specific ERP connection exists for your market, which direction it runs and who supports it are scope questions to confirm in writing—treat any connector list as a claim to verify rather than an assumption. You can review how order flow is typically structured in a distributor management system, and why distributor stock records do not match physical inventory.
Frequently asked questions
Who should own the customer master record when a DMS and an ERP are connected?
There is no universal rule. A workable default is to let the system closest to where the record is created own it, make the other side read-only, and maintain a cross-reference table that both sides use. The decisions that matter most are who may merge duplicates and how an outlet created in the field receives a finance-recognized customer code.
Should stock levels in the DMS update in real time?
Match freshness to the decision being made. Sales acceptance needs a defined rule and a visible timestamp, not a promise of instant data. Document the refresh interval, what the screen shows when data is stale, and who resolves a conflict between the DMS figure and the warehouse count.
What should happen when a message fails between the DMS and the ERP?
It should be visible, owned and recoverable: a named person monitors the queue, retries follow a rule that prevents duplicate creation, escalation has a path, and a daily reconciliation confirms the expected records actually arrived. A failed message that disappears silently into a log is the most expensive kind.
As a next step, write a one-page interface scope document using the matrix above, with a named owner for each row, and walk through it in the demonstration before you discuss commercial terms.
Put this guide into practice
This general-purpose worksheet is a starting point. Adapt its fields, responsibilities and rules to your business process.
