The quote says what to charge, not what you make

Your estimator adds a splashback to a work table and the total goes up. Whether it went up by more than the splashback costs to make is not something the quoting system can tell you. So the question of whether a job is worth taking is answered the way it always was: by whether the number looks right to you.

That is the normal state of quoting software and it is a bad one. The risk runs both ways. A job taken at a price that does not cover the making, and a job turned away that would have paid, because nobody could see the margin on a single line, only the total at the bottom. Neither shows up as a mistake on the day. Both show up at the end of the year.

What was actually going on

The system knew the selling price of everything, because that is what a quotation needs. It knew nothing about what anything cost. Without a cost beside every price, there is no margin to show, and adding a second, separate costing spreadsheet would only have produced a costing spreadsheet that was wrong, because two sets of figures kept by different people at different times always drift apart.

What we changed

Every material and every labour or process item now carries two rates: what it sells for and what it costs. The pricing rules are run twice for every feature on every line, once with selling rates and once with cost rates. The same formulas, the same steps, the same material choices, the same dimensions, both times. The difference between the two results is the gross profit on that feature; divide by the selling result and you have the margin. Add up the features and you have it for the line.

There is no second set of rules and no separate costing model to keep in step. If a pricing rule changes, the cost calculation changes with it, in the same change, by construction. The price of this is that every quote calculation does twice the work. At the scale a person quotes at, that is not noticeable, and if it ever became so, the cost run is the one to defer, because nothing the customer sees depends on it.

Two things called margin, which are not the same

This is where arguments start, and it is worth being plain about it.

There is a markup that sets the price. A retail buyer, a builder and an architect specifying for a client get different markups, applied to the selling total to produce what each customer pays. That is commercial policy and it changes what the customer is charged.

There is a gross margin that reports on the price: the gap between the cost run and the selling run. It changes nothing. It is a measurement.

Both are percentages and both get called margin in conversation. The moment a report adds them together or presents one as the other, every number in it is meaningless and looks completely plausible. So they live in separate fields with separate names. The order is fixed too: add up the per-feature selling costs, apply the customer’s markup, and that is the unit price; quantity, discount, extra charges and tax come afterwards, at the quotation level. Each stage does one job and nothing is applied twice.

What it did not fix

Per-feature margin is only as good as the cost figures behind it, and the rate card arrived with the two prices unevenly filled in. Some rows had both. Some had only a selling price. Some had only a cost.

Where one was missing it was worked out from the other: subtract an explicit margin amount if the source gave one, otherwise divide by an explicit margin percentage, otherwise apply a default markup. The default is the one that matters, because it is a fabrication. It was applied where the source said nothing at all, and the number it produces will be used to compute a margin someone may make a decision on. So every rate records where it came from: stated in the source, derived by amount, derived by percentage, or defaulted.

That provenance is recorded but it is not yet shown. The system will report a margin to two decimal places on a feature whose cost was defaulted during a migration, with no visible difference from one whose cost the supplier stated. Until that is surfaced, the per-feature margin figures should be read as indicative rather than as accounting. Without the provenance at all, a default markup applied to 40 rows during a migration becomes indistinguishable from real cost data six months later, and every margin report built on those rows is quietly fictional.

Two decisions the business made

Both narrowed the design usefully. Selling price only means something for items bought in and resold, a fridge or a branded unit. Materials consumed in fabrication are never sold as materials, so for them only the cost is real, and the margin that matters on the fabrication path is the one the customer’s markup creates.

And the markup percentage must never appear to a salesperson or on anything the customer sees. It is set by an administrator against the customer class and is invisible everywhere else. That has a consequence that is easy to miss: if any screen shows both a base figure and a final figure, anyone can recover the percentage by division. Hiding a number is not the same as hiding the information, so the check is on what can be worked out from the outputs, not just on which fields are shown.

Where this ends up

Running the rules twice is how Quote can put a margin next to a price: one pass on cost, one on selling, the same formulas both times, and the two results kept apart so neither is ever read as the other.