The total is not the sum
A vendor’s stated grand total and the sum of its own line items can differ by half a million dollars. Arithmetic is not a judgment call, so we refuse to treat it as one.
Here is something that happens more often than anyone wants to admit. A vendor quote arrives. The grand total on the cover page says one number. The line items underneath it add up to a different one.
Usually the gap is small enough to look like a rounding artifact and get waved through. Sometimes it is not small at all.
Stated grand total and the sum of its own itemization differ by $500,000.
Nobody is being dishonest. A revision got applied to a line and not to the cover. An alternate was pulled and the subtotal was never refreshed. A spreadsheet range was off by one row for six months and this is simply the first quote where the difference was big enough to see. The cause is boring. The consequence is that you either carried five hundred thousand dollars you did not need to carry, or you did not carry five hundred thousand dollars that you owe.
Twenty minutes before close is the worst possible time to find it
Quotes do not arrive evenly. They arrive in a cluster at the end, because every vendor is protecting their number from being shopped and because everyone in this business is working the same deadline. So the arithmetic check that should be routine gets performed, if at all, during the exact window when the submission clock is running and three other things are on fire.
That is not a discipline problem. It is a scheduling problem that no amount of discipline fixes.
Money is code, not a model
This is why ArosBid does not let a language model anywhere near an arithmetic operation.
Every extension, sum, reconciliation, and allowance runs as deterministic integer-cent code. Not floating point, which is its own quiet source of drift once you have chained enough operations together, and certainly not inference. Integer cents, computed the same way every time, producing the same answer every time, verifiable by anyone who wants to check it by hand.
The reading problem is hard. The arithmetic is not, and it should never be treated as though it were.
The model has a different job, and it is genuinely difficult: read a PDF that some estimating package generated in 2011, locate the itemization, work out which column is quantity and which is extension, and notice that page four continues page three’s table without repeating the header. That is a reading problem, and reading is what models are for. The instant the numbers are extracted, they are handed to code and the model is done.
What leveling produces
- Every quote normalized to the same scope lines, so that a comparison is actually a comparison.
- Each stated total reconciled against its own itemization, with the delta surfaced rather than quietly corrected.
- Exclusions lifted out of the fine print and priced as scope, because that is what an exclusion is.
- An award recommendation the estimator can accept, change, or ignore.
The second one matters most. ArosBid does not silently fix the vendor’s total. It shows you both numbers and the difference between them, because which figure is correct is a conversation with the vendor, not a decision for software. Our job is to make sure that conversation happens before you submit rather than during buyout.