Distributor Management Software: What It Has to Hold, and Why Spreadsheets Lose Money

A distributor's accounts show what the principal invoiced them and what they invoiced the trade. Neither number is the business. The business is what the outlet actually sold, what scheme was running when it sold, and whether the claim for that scheme was made, evidenced and paid.

Most distributors can see primary sales — stock in, from the principal — perfectly well, because it arrives as an invoice. Secondary sales, the movement from distributor to outlet, are frequently invisible at outlet level, which means sell-through is a guess and the figures that decide margin are reconstructed at month end by somebody with a spreadsheet and a deadline.

That reconstruction is where the money goes. A scheme claim that nobody assembled is a claim nobody made, and a claim without evidence attached is one the principal declines. Both outcomes look identical in the accounts: margin that was earned and never arrived.

Distributor management software is not an ERP with a sales app bolted on. It is a reconciliation engine wearing an order-taking interface, and the test of whether it works is not whether an order can be placed. It is whether every figure in it survives a principal's audit three months later.

What the system actually has to hold

Six things, and only one of them is order entry.

An outlet master with coverage, meaning not just who your customers are but which were visited, by whom, on what beat, and which were skipped. Coverage is the operational metric a distributor is judged on by its principals, and it cannot be derived from invoices because a visit that produced no order still happened.

A scheme engine that can express what the principal actually ran: quantity slabs, combination offers, period-limited promotions, outlet-class-specific rates, and schemes that change mid-month. This is the piece most often simplified into a discount percentage, and the simplification is where claims start failing.

Claim generation, automatic, with the evidence attached at the point of sale rather than assembled afterwards. Credit control that blocks at order capture, not at invoicing, because an order accepted and then blocked has already consumed a salesman's visit. Sell-through reporting at outlet level. And ERP and e-invoicing integration, which in Oman means being Fawtara and Bayan aware rather than generically "tax compliant".

Schemes are a rules engine, not a discount field

The single most common under-specification in this category. A scheme looks like a percentage until you list what principals actually run.

Quantity slabs, where buying 10 earns one rate and 12 earns another, with the boundary resolved at the line or at the invoice depending on the scheme. Combination offers, where buying across two SKUs unlocks a third. Period schemes that start and stop mid-month, so the same product sold on the 14th and the 16th earns differently. Outlet-class schemes, where a wholesaler and a kirana get different rates for identical quantities. And schemes that stack, or explicitly do not, with an order of precedence somebody has to decide.

A discount field cannot hold any of that, so what happens in practice is that the field holds the simple cases and the complex ones live in a parallel spreadsheet. The parallel spreadsheet is the single largest source of unclaimed margin in distribution, because it is maintained by one person, it is not reconciled, and it is not evidence.

The design rule that works: the scheme is a rule applied at capture, and the claim is its output, generated at the same moment. If the claim is assembled later from transaction history, you are reconstructing an intention from its effects, which works until a scheme changed mid-period.

Versioning matters here for the same reason it does in any system where money and time interact. A scheme has a history, and a claim raised in November for a sale in September has to apply September's rules. Store the scheme as a current state and the September rate is gone; store it as versions with effective dates and the claim regenerates correctly from the data. This is the same discipline as effective dating in a policy or a tenancy, and it is cheap at the start for the same reason it is expensive later.

Coverage is the metric principals judge you on

Distributors are measured on more than volume, and the second metric is coverage: how much of the territory is actually being served.

That breaks into numbers the system has to produce rather than estimate. Outlets on the beat plan against outlets visited. Visits made against productive calls, a productive call being one that produced an order rather than a conversation. Lines per call, which tells a principal whether their full range is being pushed or only the easy movers. And the frequency pattern — an outlet meant to be visited weekly that is in fact seen fortnightly is a coverage failure invisible in sales totals.

None of these can be derived from invoices, which is the point. A visit that produced no order still happened, and a system that only records transactions has no way to distinguish a territory being worked without success from one not being worked at all. Those two situations need opposite responses from management.

Capturing it means the field app records the visit itself, with a reason code when no order follows, and ideally a location stamp so the record is evidence rather than assertion. That is a small amount of engineering and a significant amount of change management, because it is the first time the field force's day becomes visible.

Offline is the default, not the exception

Field coverage is unreliable almost everywhere this software is used, so the app has to assume no connection and treat a connection as a bonus.

That turns ordinary features into distributed-systems problems. Pricing and schemes have to resolve locally, which means the rules travel to the device and stay current. Credit exposure has to be available locally, with an age so the salesman knows how much to trust it. Orders written offline are claims that reconcile later, and two salesmen can commit the same van stock before either syncs.

The resolutions are ordinary once decided and expensive once discovered: a rule per field for who wins a conflict, a sequence that preserves the time an action happened rather than the time it synced, and an explicit tolerance for stale data rather than a silent assumption that local equals true.

The invoice is the sharpest case. In van sales the document is produced at the door and the outlet keeps it, so the number on that paper is final whether or not the back office agrees later. Everything downstream has to accommodate a document that already exists in the world.

Claims fail on evidence, not arithmetic

Principals do not generally dispute the maths. They dispute whether the transaction happened as described.

So the claim has to carry its proof: which outlet, which invoice, which scheme version, what quantity, on what date, under which rate. Attached at the moment of sale, not compiled afterwards, because the compilation step is where ambiguity enters and where a principal's auditor finds the gap.

Reconciliation against principal credit notes is the other half, and it is the half that is almost always manual. The distributor claims, the principal settles — often partially, often late, often with its own reference rather than yours — and somebody has to match settlements to claims, identify shortfalls and chase them. A system that generates claims but cannot reconcile what came back has automated the easy half and left the valuable half on a desk.

The uncomfortable truth here: a claim you cannot evidence is a claim you have funded on the principal's behalf. Distributors discover their real claim leakage only when somebody finally reconciles a year, and the number is routinely larger than anyone expected.

Worth adding one number to your own reporting before any software decision: claims raised against claims settled, by principal, by month. It takes an afternoon to assemble from whatever records exist, it needs no system to produce, and it tells you whether this is a problem worth solving. A distributor whose settlement rate is above ninety-five percent has a different priority from one sitting at seventy, and most have never calculated it.

Credit has to block at capture

A salesman in the field takes an order from an outlet that is over its limit. What happens next decides whether your credit policy is real.

If the block happens at invoicing, in the back office, the order has already consumed a visit, the outlet has been promised stock, and someone now has to call and withdraw it. That call is rarely made, so the order ships, and the credit limit becomes advisory.

Blocking at capture means the field app knows the outlet's exposure before the order is written — which means the exposure has to be available offline, because coverage is not guaranteed in the field. That is the engineering requirement hiding inside a policy decision: a locally held, recently synchronised credit position, with a rule for what happens when the local data is stale.

Most distributors settle on a tolerance: block hard above a threshold, warn and allow with approval below it, and age the local data so a salesman knows when the figure cannot be trusted. All three are configuration rather than code, if the system was built expecting them.

Van sales and pre-sales are different systems

They are often specified as one flow with a toggle, and they are not.

Pre-sales separates the order from the delivery. A salesman visits, takes an order, the warehouse picks it, a vehicle delivers it later. Stock lives in the warehouse, the order is a promise, and the invoice follows fulfilment.

Van sales collapses the two. The vehicle carries stock, the order is written and fulfilled at the outlet, and the invoice is produced at the door. That makes the van a mobile warehouse with its own stock position, which has to be loaded, reconciled at end of day, and accounted for when a unit is damaged or returned. It also means pricing, scheme application and invoicing all have to work offline and produce a document the outlet keeps.

A distributor running both — and many do, by territory or by product line — needs both flows properly, not one flow with exceptions. Specifying them as one is a reliable way to get a system that serves neither well.

The secondary sales upload nobody remembers

A small feature with an outsized effect, and worth naming because it is so often left as a manual step.

Principals require secondary sales data: what moved from you to the trade, at outlet level, usually on their format and their schedule. When that upload is a person exporting a file and attaching it to an email, it happens late, it happens inconsistently, and when that person is on leave it does not happen at all. The consequence is not just an annoyed principal; it is schemes settled on incomplete data.

Build it as a scheduled job that runs whether or not somebody remembers, with the failure case being an alert rather than silence. Keep a record of what was sent and when, because the first dispute about a settled scheme will turn on whether the principal received the data in time, and an email sent from somebody's outbox is not a record either side can rely on. It is a small piece of work with a direct effect on how much of your claim gets paid, and it is the clearest example of why this category rewards reliability over features.

Three operator shapes, three different systems

Worth establishing which you are, because the words overlap and the builds do not.

A distributor with a field force needs everything above: coverage, schemes, claims, credit, secondary sales. This is the full DMS.

A 3PL or bonded warehouse operator has a different problem entirely. Multiple clients in one building, and activity billing — pallet day, per pick, per carton, kitting tariffs — reconstructed by hand after month end, with value-added work going unbilled because nobody logged it at the time. That is an activity-capture and billing system, not a sales system, and almost none of the scheme machinery applies.

A cash-and-carry wholesaler has counter sales and delivered sales competing for one stock position, which is primarily an availability and allocation problem rather than a claims one.

All three get called distribution software. Establishing which one you are is the first thing discovery settles, and it changes the build more than any feature on a requirements list.

A fourth shape is increasingly common and sits awkwardly between them: the distributor who also sells direct, running a trade business and a consumer channel from the same stock. That creates an allocation question nobody owns — when stock is short, who gets it, and is that decision a rule or a phone call? It also creates a pricing exposure, because trade pricing is contractual and consumer pricing is public, and publishing one can undermine the other. If that describes you, settle the allocation rule and the price visibility boundary before anything else, because both reach into the order, stock and pricing models simultaneously.

Where these builds fail

Not in order entry, which every vendor demonstrates well.

They fail when the scheme engine cannot express a real scheme, so the complex ones move to a spreadsheet and the claims from them are made inconsistently or not at all. They fail when claims are generated but settlements cannot be reconciled, so shortfalls go unchased and nobody knows the leakage figure. They fail when credit blocks in the back office rather than in the field, so the policy is advisory and the exposure grows. And they fail when van sales was treated as pre-sales with a flag, so the van's own stock position is never properly reconciled.

Every one of those is a question about what the floor and the field already do, and in what units. That is what discovery is for in this sector: not a feature list, but an inventory of the actual operation — which schemes run, who settles what, where coverage is unreliable, and which of the three operator shapes above you actually are.