Your order automation is quoting list price to customers who negotiated something else

Overcharging produces a phone call. Undercharging produces silence.

That asymmetry is why pricing bugs in order automation survive for years. Charge a customer more than the contract says and someone in their accounts payable team eventually notices. Charge them less and nobody anywhere has a reason to raise it. The margin just quietly is not there, and in the monthly report it looks like a weak product line rather than a broken integration.

We found one of these last spring at a medical supplies distributor. Their order portal fed the ERP automatically: webhook in, order created, line items created, unit price taken from the product master. It had been running for over a year. It was wrong for every customer with negotiated terms, in both directions, and the only reason it surfaced at all was a purchasing manager at one hospital who checked a consolidated invoice line by line.

Price is not an attribute of the product

The product master holds a list price. That is a starting number, not a selling price.

What a given customer actually pays comes out of a chain: their account, the price list assigned to it, any contract and its term, volume breaks, promotional pricing, the product's discount group, sometimes a small order surcharge. ERPs call this pricing or price determination, and it is a real piece of logic. It usually contains more branching than the entire workflow that creates the order.

The workflow does not call it. It reads the product record, sees a field called price, and copies the value into the line.

Why the API hands you a number anyway

The product endpoint returns a price because it has to return something. It does not know which customer is ordering, so it gives you the default.

Price determination runs somewhere else: at the moment the order line is created. Send the product, the account, the quantity and the date, leave the price field empty, and the system calculates. Send a price and the system accepts it without calculating.

That behaviour is deliberate. Sales needs to be able to override a contract price on a specific deal, so the field has to be writable. The problem is that a workflow does the same thing on every line of every order, and nobody made that decision. In both other cases we have looked at since, the reason was identical: whoever built the integration was not sure whether the price field was mandatory, so they filled it in.

Volume breaks do not survive a loop

Tiered pricing depends on quantity. One to nine at one price, ten to forty nine at another, fifty and above at a third.

A workflow that creates line items one at a time inside a loop submits one quantity per call. If the portal produces three separate lines for the same product, which portals do all the time, the ERP prices three small quantities instead of one large one. The customer loses the tier they actually earned.

Order splitting does the same thing. Split a shipment across two warehouses or two orders because of availability, and the quantity that would have crossed a break is now two quantities that do not. The customer pays extra because of how the supplier organises fulfilment, which is a hard thing to explain when it comes up.

At the distributor this hit 41 orders in a year. Small amounts each time, which is exactly why no one called.

Prices expire, integrations rarely do

Contracts end. Price lists start on a date. A promotion that applied in June does not apply in July.

We keep finding automations that read a price list once, wrote it to Airtable or a Google Sheet to save API calls, and never refreshed it. At the distributor there was one of those too, holding the previous year's numbers, feeding the prices the portal displays before checkout.

There is also the question of which date governs. Order date, confirmation date and shipping date drift apart, particularly for backorders that cross a year boundary. The ERP has a rule about which one it uses. A workflow that sets the price itself is implicitly using the day it happened to run.

The wrong price does not stay in the order

An order price is not a dead end. It flows into the invoice, into revenue reporting, into per customer margin, and into the numbers someone uses in the autumn to negotiate next year's terms. A customer who has been systematically undercharged looks unprofitable in that analysis and may well end up with worse terms because of a mistake the supplier made.

Returns extend the problem. A credit note has to refund what the original invoice charged. Automations that generate credit notes from a returns form usually fetch the price from the product master, because that is the path they already know. If the invoice was too high, the credit refunds too little and the customer absorbs the difference. On a promotional item whose promotion has since ended, the refund can land well below what was actually paid.

Then there is the cleanup, which is the worst part. Fourteen months of wrong prices meant 340 affected lines at this distributor, spread across invoices that had long been paid. Reissuing invoices across a closed period is a tax question and a sales relationship question, not a technical one. The workflow was fixed in an afternoon. Sorting out the history took six weeks.

What we specify for order integrations

Price comes from the system that owns price determination. The workflow sends product, account, quantity and date, and leaves the price field alone. Anything else means reimplementing the ERP's commercial logic inside a workflow, where it starts going stale on day one and nobody maintains it.

If the portal has to show a price before the order exists, that is two calls. Ask the ERP for a price for this account and quantity, then place the order. Give the quoted price a short validity, a few minutes. If the price at creation differs from the quote, the order goes to review instead of going through.

Line items go in as one call, not one per iteration. Duplicate products get merged first. If an order gets split for operational reasons, it still gets priced as a single quantity.

Every line gets a sanity check against list price. Discounts beyond an agreed threshold, and anything below cost, route to a human. The check does not slow down normal orders, it catches configuration mistakes before the invoice leaves the building.

The log records where the price came from: list, contract, tier, promotion or manual override, with an identifier. Without that field, the next investigation costs what this one did, which was fourteen months of invoices and an afternoon of someone's time in purchasing.

An hour will tell you

Take your five customers with the most negotiated terms. Pull ten automatically created order lines from each of the last three months and compare the invoiced price against what your ERP's price determination returns for that account, that quantity and that date.

Then check the tier cases specifically: orders with the same product on multiple lines, and orders that were split.

Fifty lines with no discrepancy means pricing is wired up correctly. One discrepancy means it applies to every order that customer has placed since go live, and the question becomes how far back you are willing to go.