What allocation means
Unit allocation is the act of assigning one specific, serialized unit to exactly one order. The serial is usually a VIN. Until that assignment happens, an order is a request for "a machine of this model". After it happens, the order is a claim on a particular machine with a particular history, location and cost.
The distinction matters because a distributor does not sell models. A distributor sells units. Each unit has its own landed cost, its own condition, its own arrival date, and its own place in a warehouse, a container or a dealer lot. Two units of the same model can carry different margins. Treating them as interchangeable is where most reconciliation problems start.
A sound allocation rule is short: one unit, one active order, at any moment. Everything else in this article follows from protecting that rule.
Stock orders and future orders
There are two common ways a dealer asks for a unit.
- Stock order. The unit already exists in the distributor's inventory. Allocation can happen immediately because the VIN is known.
- Future order (pre-order). The unit is on an incoming shipment, or not yet built. The order is placed against expected supply. The VIN may not exist in the system yet, so the order waits, and allocation completes once the shipment is received and serial numbers are recorded.
A future order is an order whose allocation is deferred. The system should still show which shipment it expects to be filled from.
Why two orders want the same unit
The same unit can be wanted by two orders at once, and this is normal. A dealer in one region requests the last unit of a popular model. Another dealer requests the same model an hour later, and the sales rep knows the unit is physically sitting in the nearest warehouse. A future order is waiting for a shipment that contains that unit. A retail customer walks in and asks to see it.
None of this is a mistake by anyone. The mistake is letting both orders believe they own the machine.
The system, not the people, has to decide. That means the assignment is an atomic operation: when two requests arrive close together, one succeeds and the other is told plainly that the unit is taken. A spreadsheet cannot do this reliably, and neither can a status field that anyone can edit. The check and the write must happen as one step, so the loser of the race sees a refusal rather than a silent overwrite.
The usual lifecycle
Most serialized equipment follows the same path, with local variations.
- Available. The unit is in inventory and unassigned.
- Reserved or allocated. The unit is attached to one order. Nobody else can take it.
- Invoiced. An invoice has been issued for that unit. The sale is now a financial fact.
- Paid. Payment has been received and applied.
- Delivered. The unit has left the distributor's control and reached the dealer or end customer.
Each step should leave a record: who did it, when, and on which document. The unit's current status is then a summary of those records, not a free-text field someone typed over.
A reservation can usually be released with little consequence. An issued invoice cannot simply disappear, because it may already be in someone else's books.
When a deal changes
Deals change constantly. A dealer's financing falls through. A customer picks a different colour. A unit is damaged in transit. A price was entered incorrectly. A dealer cancels a future order before the shipment lands.
The right response depends on how far along the unit is, and the system should make the right response the easy one.
- Before invoicing, release the allocation. The unit returns to available, and the order shows that it released the unit, when and why.
- After invoicing, void the invoice with a reversal. The unit goes back to available only because the reversal says so.
- After payment, reverse the payment as well, so that the receivable, the cash record and the unit status all move back together.
In each case the previous state is restored by adding a record, not by erasing one.
Releasing a unit is not deleting a sale
These two actions are often confused, and the confusion is expensive.
Releasing a unit means the order no longer holds that machine. The unit goes back into the pool and can be allocated elsewhere. The order itself, and everything that happened to it, stays on the record.
Deleting a sale means pretending the transaction never took place. It removes the evidence that a dealer ordered, that someone approved, that an invoice was issued, and that the unit once belonged to someone else.
An allocation can be released many times in the life of an order without damaging anything, as long as every release is itself recorded. A sale that has been invoiced is different: it is a commitment that has already left the building, and the only honest way to undo it is to say so on the record.
The reversal principle
Accountants call it storno: a correction made by posting an opposite entry instead of altering the original. The principle is simple to state.
Never delete or silently zero a posted transaction. Create a linked reversal record, with a stated reason, that travels back through the same downstream records the original touched, so the net effect is zero and the evidence survives.
Take an invoiced sale that must be cancelled. The original posting affected several places: the unit's status moved to sold, cost of goods was recognized, a receivable was opened, perhaps a commission accrued. A proper reversal is its own document, linked to the original, carrying a reason such as "customer financing declined". That document then flows back through the same places. The unit returns to available. The cost entry is offset. The receivable is cleared. If payment had been taken, the payment status reverses too.
Afterwards, both the original and the reversal remain visible. Anyone reading the history can see what was sold, what was undone, who did it, and why.
Why deletion breaks audits and reconciliation
Deleting a row looks tidy. It also causes several problems that surface later.
- Gaps in numbering. Invoice and order numbers are normally sequential. A missing number invites the question of what was removed, and no one can answer it.
- Orphaned downstream records. If the sale is deleted but the cost entry remains, or the reverse, inventory value and cost of goods disagree with each other. The books no longer reconcile with the warehouse.
- Lost reasons. Cancellation reasons are valuable data. They show where financing fails, which models get returned, and which dealers change their minds. A deleted record carries no reason.
- No defence in a dispute. When a dealer says "we never ordered that" or "you cancelled that", the history is the only evidence either side has.
- Quiet misuse. If a lower-privileged user can delete what a higher-privileged one committed, the system is trusting the wrong person. Undoing a committed transaction should require a higher role, a reason, and leave a trace.
Silently zeroing a record, keeping the row but setting the amount to nothing, is the same problem in a quieter form.
Four-eyes approval for price changes
Pricing errors are usually honest: someone imports the wrong file or moves a decimal. Four-eyes approval is the control for this: the person who prepares a price change is not the person who approves it.
The important word is enforced. Many businesses have a policy that says a second person should review prices. A policy relies on everyone following it on a busy day. A system rule is different: the approval step rejects the approval if the approver and the preparer are the same login. No setting to skip, no administrator exception, and a record of both names against the change.
Prices should also take effect through a distinct step. Preparing a batch does not change what dealers pay. Approval does. That separation means a wrong batch can be rejected before it touches a single order.
A checklist for evaluating your own system
Ask these questions of your current software or spreadsheet process.
- Can the same serialized unit be attached to two active orders at the same time, even briefly?
- Does a future order show which shipment it is waiting on, and what happens when that shipment arrives short?
- When an invoice is cancelled, does the system create a linked reversal with a reason, or does someone delete the row?
- Does a reversal return the unit status, cost of goods and payment status to where they were, in one action?
- Can a user with limited permissions undo something a manager committed?
- If you pick any missing invoice number, can you explain what happened to it?
- Can one person prepare and approve the same price change, and does the system, rather than a policy document, prevent it?
If several answers are "I am not sure", the records are kept up by habit rather than by the system.
Summary
Unit allocation assigns one serialized unit to one order at a time, and the system must refuse a second claim rather than let people sort it out later. When a deal changes, reverse it with a linked, explained record that flows back through inventory, cost and payment, and never delete or silently zero what was posted.