TL;DR
- Two systems doing "the same" math should be expected to produce different results. Rounding isn't associative — round-then-multiply and multiply-then-round are not the same operation.
- Day count conventions (30/360, Actual/365, Actual/Actual) produce different fractions for the same stretch of time. A system prorating on one convention and invoicing on another will never tie out, even with a perfect formula.
- AI adds non-determinism risk: a model generating an answer in prose isn't guaranteed to compute it the same way twice, unless it's calling deterministic code underneath.
- The fix: same order of operations, same rounding rule, same day count convention — every time, in one system.
Every few months, the internet re-discovers the same math meme, a deceptively simple equation like 6÷2(1+2), and a comment section split down the middle because everyone quietly disagrees on the order of operations. It's a good joke. It's also one of the most common ways quote-to-cash math quietly comes apart at the seams.
There's a basic accounting fundamental underneath all of it, the contractual price has to equal the amount you invoice. Accounting actually has names for this. ASC 606 calls that number the transaction price, which is supposed to survive unchanged from contract to invoice. Finance teams call the tie-out itself bookings-to-billings reconciliation, what the customer signed has to reconcile with what you billed them.
Sell widgets with no discount, and that's price times quantity, easy enough. Add a discount, and now you're doing fraction math, because a discount is really a ratio applied as a multiplier, 15% off means multiplying the price by 85/100, and a ratio like that doesn't always divide evenly. Renewal uplifts work the same way, since a 5% increase is the same ratio-as-multiplier logic just running in the other direction. And sometimes the price itself is a fraction, because not everything is priced in whole dollars.
Here's the part that doesn't get said out loud enough, if two different systems are both doing "the same" math, you should expect a different result, not a rounding-error-sized difference, a genuinely different number. That's because rounding isn't associative. Round-then-multiply and multiply-then-round aren't the same operation. Apply a discount to each line and sum, versus sum the lines and apply the discount once, both are correct, and they don't have to agree. There's no universal "right" order. There's only whichever order you've chosen, applied identically everywhere. This isn't "new math," where you take the long way and land on the same answer. It's a different answer entirely.
AI isn't going to change the number of days in a month, either. Now complicate a fractional price with fractional time (I'm not going to argue with Doctor Who about whether time bends. We already know accounting does). What's the price of an upgrade prorated into an existing subscription? How much credit is due on a downgrade or cancellation? Nobody argues there are 12 months in a year. But how many days are in a month? Depends on the month. Average it out and, surprise, you get a fraction again.
Finance already has a name for this exact problem, a day count convention. 30/360 pretends every month has 30 days. Actual/365 uses real calendar days over a fixed 365. Actual/Actual uses the real days in the real period. None of these is "more correct", they're just different rules that produce different fractions of a month for the same stretch of time, which is why a system prorating on one convention and invoicing on another will never tie out, even with a perfect formula.
If you want price to equal invoice, you get two options, deal only in whole dollars and whole months, or make sure the same rules calculate the contract price and the invoice amount, same order of operations, same rounding rule, same day count convention, every time. That second option gets harder with AI in the loop. Traditional code runs the same steps on the same input every time, a model generating an answer in prose isn't guaranteed to compute it the same way twice, unless it's actually calling deterministic code to do the arithmetic rather than reasoning its way to a number. "The same system" only holds if it's still deterministic underneath.
And before you hand this off to AI and throw out the abacus (check with Antiques Roadshow first, some of those things are apparently worth more than the AI subscription), 2026 research on "deskilling" is already showing people get measurably worse at unaided math after leaning on AI to do it for them. That's fine, right up until the AI drafting your quote and the AI calculating your invoice quietly disagree on the rules, and nobody left in the building can catch it.
A friend, when I left my last job, wished me a career where I'd never have to explain this problem again. Turns out, I love this problem. It's why I work in quote to cash.
Math is hard enough. Don't make it harder.
What's the problem you can't quit explaining?
Frequently asked questions
Why do my booking and billing numbers not match?
Booking and billing numbers often differ because your CRM and ERP calculate the same contract independently, using different rounding rules or day count conventions. Both systems can produce a correct result by their own logic and still arrive at different totals. The cause is not corrupted data. It is two independent calculations applied to the same contract.
What is bookings-to-billings reconciliation?
Bookings-to-billings reconciliation is the process of confirming that the amount on the signed contract matches the amount on the invoice. Under ASC 606, the transaction price agreed at contract signing should remain consistent through to the billing event. When a CRM and an ERP calculate it independently, reconciliation is required to find and resolve the differences that result.
What is a day count convention in billing?
A day count convention is the rule a billing system uses to calculate partial-period amounts, most commonly for proration on upgrades, downgrades, or cancellations. The three most common are 30/360, Actual/365, and Actual/Actual. None is universally more correct than the others. When two systems use different conventions for the same calculation, their proration amounts will differ even when both apply the correct formula.
Why is rounding causing my invoice to not match the contract?
Rounding in billing is not associative: round-then-multiply and multiply-then-round produce different results. When two systems independently apply a discount or calculate a line total and each rounds at a different point in the calculation, the totals can diverge. The fix is a single rounding rule applied consistently across all systems at the same point in every calculation.
Can AI fix billing discrepancies between a CRM and an ERP?
AI can help identify exceptions and flag anomalies, but it does not resolve the root cause of billing discrepancies. The root cause is two systems independently calculating the same number using different rules. Fixing that requires shared calculation logic, not better exception detection. AI also introduces a non-determinism risk: language models do not guarantee the same arithmetic result on the same input the way deterministic billing code does.