The Quote Said $240K, the Invoice Said $261K, and Both Systems Were "Right"

The deal closed at $240,000 on the quote. The invoice went out at $261,300. Nobody committed fraud and no field got fat-fingered; both systems were doing exactly what they were told. The quote prorated a mid-month start using a 30-day month and rounded each line to the dollar. The billing system prorated on actual days and carried four decimals, then summed. Multiply a small per-line difference across forty line items and a multi-year ramp, and you get a $21,300 gap on one deal that took finance three days to explain and a very uncomfortable call with the customer to resolve. The CPQ was fast. It just did not tie out.

That is the tension every CPQ build lives inside. Sales wants a quote in minutes, so you push logic into config that generates numbers quickly. Finance needs those numbers to reconcile to the invoice and the revenue schedule to the penny, because a quote that does not match the invoice is a quote that generates disputes, restatements, and mistrust. The two goals are not in conflict if you design for both from the start. They only collide when you optimize the quote for speed and leave reconciliation as someone else’s problem downstream.

The gap is almost always rounding, proration, and term math

When a quote and an invoice disagree, the cause is rarely a wrong price. It is that the same calculation ran twice with different rules. Three culprits account for nearly every gap I have chased. Rounding: does each line round to the dollar, or does only the total round, and to how many decimals do you carry the intermediate math? Proration: does a mid-term start prorate on a 30-day month, a 365-day year, or actual days in the actual months? Term math: on a multi-year ramp, does year two’s uplift compound on the discounted year-one price or the list price? Pick a rule for each, implement it once, and the systems agree. Leave any of the three implicit and the two systems will each guess, differently.

Design the calc once, consume it everywhere

The architectural fix is to make the price calculation a single source that both the quote and the billing feed read, rather than two implementations that happen to agree most of the time. In a Salesforce CPQ context, that means the quote line calculations, the order and contract that generate from them, and the payload you send to billing all derive from the same price rules and the same rounding and proration configuration. If billing lives in a separate system, the reconciliation contract is the order: the quote produces an order with per-line net amounts and a schedule, and billing invoices against that order rather than recomputing from list price and its own proration.

Pin the math rules in metadata, not in a formula field

The proration and rounding rules should be explicit configuration a human owns, not implicit behavior buried in a formula field that a well-meaning admin edits without knowing billing depends on it. When I inherited the mismatched org, the quote’s proration was a formula field on the quote line and billing’s was a setting in the billing platform, and neither team knew the other existed. Making the rule a named, owned config value on both sides, with the same definition written down, is what closed the gap and kept it closed.

// Proration is ONE decision, applied everywhere. Actual/actual, carry 4 dp,
// round the line, not the intermediate. Both the quote and the order-to-billing
// payload call this, so they cannot diverge.
public static Decimal proratedAmount(Decimal annualPrice, Date start, Date end) {
    Integer daysInTerm = start.daysBetween(end) + 1;
    Integer daysInYear = Date.isLeapYear(start.year()) ? 366 : 365;
    Decimal raw = annualPrice * (Decimal.valueOf(daysInTerm) / daysInYear);
    return raw.setScale(2, System.RoundingMode.HALF_UP); // round the line, once
}

The worked example: the same deal, tied to the penny

Fast-but-unreconciled versus fast-and-tied-out

Here is how I design CPQ to tie out

The $21,300 gap was never a pricing mistake. Both systems were right by their own rules; the rules just never matched, because proration and rounding lived in two places nobody had reconciled. A fast quote and a quote that ties out are the same build if you decide the math once, implement it in a single shared calc, and make the order the contract billing invoices against. Speed for sales and reconciliation for finance are not a trade. They are two requirements of one well-designed system, and the deal that ties to the penny is the one nobody has to spend three days explaining. The same single-source discipline is why every integration needs reconciliation built in from day one, so a dropped or mis-mapped record surfaces the same day instead of at quarter close.