Once a supplier can accept a quote directly, the netback the platform computes is a price the operator is bound by. If it differs from what the trader would have produced in their own workbook, the operator is exposed on every quote. The exposure is silent, because a wrong netback looks exactly like a right one. It is a plausible number on a phone screen that a supplier taps to accept.
A netback is simple arithmetic, which is exactly why two systems can disagree about it.
A netback works backwards from the market. Start with the price the material will fetch where it is finally sold. Subtract everything it costs to get it there: transport, handling, processing, the costs of the transaction itself, and the trader's margin. What remains is the most the trader can pay at the point of origin and still make the trade worth doing. That remainder is what a supplier is quoted. The idea is common across physical commodities, from crude oil to recovered materials, because a seller far from the market needs to know what their goods are worth where they stand.
Each step in that chain can involve a conversion, between units, between currencies, between a market's quoting convention and a supplier's, and each conversion can round. Rounding is not one operation. Rounding half away from zero, which most people learn at school and which spreadsheets use, sends a value that sits exactly halfway between two candidates away from zero. Rounding half to even, often called banker's rounding, sends it to whichever neighbour ends in an even digit, which stops totals drifting upward when many values are summed. Several programming languages and some database functions use that rule, or another, by default.
There is a second source of disagreement that surprises even engineers. Computers usually store decimals in binary, and most decimal fractions have no exact binary form. The value 2.15 is stored as a number very slightly below 2.15. A spreadsheet rounding it to one decimal place returns 2.2. A common rounding function in application code rounds the stored binary value faithfully and returns 2.1. Both are doing exactly what they were built to do.
A spreadsheet cell also holds two values: the one it stores and the one it shows. A cell can store many decimal places and display two. Exporting a workbook to CSV usually writes what is shown. A test that compares an engine against that export is comparing against a number the spreadsheet has already rounded by its own rules, so a rounding difference between the engine and the workbook cannot appear in it.
Parity had to be proven against the trader's own historic quotes, read at the values the workbook actually stores, before any supplier saw an executable price. The trap is rounding. A spreadsheet rounds half away from zero, so 2.15 becomes 2.2. Common implementations in application code and in the database can return 2.1 on the same input. A parity harness built from a CSV export cannot detect this at all, because the export writes what each cell displays. The test then compares the engine against a number that has already been rounded, and agrees with itself.
Pricing engines drift from the workbook in the cases nobody checked.
Reimplementing a trader's workbook in code looks like a translation exercise. The formula is short, a few examples are checked by hand, and they match. They match because most values are nowhere near a rounding boundary. Divergence appears only when an intermediate value lands on or near a tie, or when a chain of conversions rounds at a different step, and those cases are rare enough to miss in a spot check and common enough to appear in production.
The second pattern is a test that cannot fail. A harness is built by exporting the workbook to CSV and comparing the engine's output against it. The export carries displayed values, already rounded the spreadsheet's way, so the harness compares the engine with a number shaped to agree with it. The other quiet source of divergence is entitlement: which adjustments a particular counterparty is entitled to. A workbook encodes that in which rows a trader chooses to use. Code has to encode it as configuration, and a mismatch there produces a confident, wrong price for one supplier.
The reflex, and the fix.
Reimplement the formula and check a few results
The formula is not complicated, and a handful of matching results feels like proof.
Rounding and entitlement differences hide in the cases nobody spot-checked. They surface as a wrong executable quote that a supplier has already accepted, and never as a failing test.
A parity harness over historic quotes at stored precision
Extracting stored workbook values directly, with no export in between, and pinning the rounding mode explicitly in the engine.
Parity demonstrated to the cent across the quotes the business actually made, with every divergence found in a harness and none found in a binding quote.
Test at stored precision with the rounding mode pinned, because the displayed value is the one place a rounding bug is guaranteed to be invisible.
Read stored values, never the export
The harness reads the precision the workbook stores. A CSV export writes what the cell displays, which silently bakes in the very rounding the test exists to check.
Pin the rounding mode in the engine
The engine states its rounding rule explicitly. It does not inherit whichever rule the language or the database happens to use, so the behaviour is a decision and not an accident of the stack.
Compare against the business's own history
Parity is proven against quotes the trader actually issued. That is the only benchmark a trader will accept, and the only one that covers the cases that genuinely occur.
Report each divergence with its cause
A mismatch is surfaced with its cause, rounding or entitlement. Nothing is tuned away until the totals happen to agree.
Flag the case with no history
A pricing case the trader never quoted has nothing to compare against. The engine marks it as unknown and does not guess.
What each choice cost, and what it bought.
AReading stored values, with no export in between
An export is the easiest way to get numbers out of a workbook, and every tool accepts CSV. Reading the stored precision directly meant more extraction work and some care with how the workbook represents its values. It was the only version of the harness that could fail on a rounding difference. Anything built on the export would have reported parity whether or not it existed, which is worse than having no test.
BPinning the rounding mode explicitly
The engine could have relied on its language's default and been correct most of the time. Stating the rule explicitly, and using decimal arithmetic where the spreadsheet's behaviour depends on it, made the engine slightly more verbose. It turned rounding from something the stack decides into something the business decided, and it means a later change of language or database cannot quietly change a price.
CBenchmarking against the trader's own history
A synthetic test set is quicker to build and easier to control. It also only covers the cases its author thought of. Using the quotes the trader had really issued cost the effort of assembling them, and bought the one benchmark the trader would trust: their own past numbers, reproduced. It also put the cases that actually occur at the centre of the test, weighted the way the business experiences them.
DReporting divergence by cause
When totals disagree slightly, the tempting fix is to adjust until they agree. That hides the cause and guarantees it returns. Each mismatch was instead reported with its cause, rounding or entitlement, so the fix went to the right place. Sign-off was slower, and every divergence that remained was understood. Cases with no historic precedent are flagged as unknown, because a guess presented as a netback is the very thing the harness exists to prevent.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
No measured figures are published for this engagement. Outcomes are described qualitatively.
A reimplemented formula that agrees on the examples somebody checked, and a harness built from a CSV export that confirms it by comparing against values that were already rounded.
A netback engine with its rounding mode pinned explicitly, proven to the cent against the business's own historic quotes read at stored workbook precision, with every divergence reported by cause.
What it owns, and what it hands to a person.
Parity is proven against the quotes in the harness and nowhere else. A pricing case the business never quoted is untested until it occurs. The engine flags that case as unknown, and a person prices it. Pricing rules that were never elicited from the trader are outside the engine entirely.
Wherever a machine's number must equal a person's number, pin the rounding mode, test at stored precision, and never treat an export of displayed values as the source of truth. Invoicing, tax calculation, payroll and interest accrual all fail in exactly this way.
A netback is the market price minus every cost of getting material to market, and it tells a seller what their goods are worth where they stand.
Rounding is a family of rules, not one operation. Spreadsheets, languages and databases can each use a different one by default, so state the rule explicitly.
Most decimal fractions have no exact binary form, so a value that is exactly halfway on paper may sit slightly below halfway in a computer, and round differently.
A CSV export writes what cells display, not what they store. A test built from it has already absorbed the rounding it is supposed to check.
When two numbers must match, report every mismatch with its cause. Adjusting until the totals agree hides the fault and guarantees it returns.