How PaxExact computes an estimate total

Every dollar figure PaxExact reports on an estimate — a line total, a room total, a project subtotal, the overhead and profit amount, the final total — is computed on the server as an exact decimal amount in cents, in USD, and rounded with a single fixed rule: ROUND_HALF_UP. No total anywhere in the contract is a client-side calculation.

That rule matters for consumers of the estimate: display the figures PaxExact returns; do not re-derive a total from the line items and expect it to match to the cent under a different rounding convention. The published rounding rule is the only one used, at every level of the total.

The reason this is worth stating plainly is that floating-point arithmetic and inconsistent rounding are a well-known source of one-cent disagreements between a server total and a client's own recalculation — two implementations can each be individually correct and still disagree by a cent on a large estimate. PaxExact removes that class of disagreement by computing every money figure exactly once, on the server, with one documented rule, and by publishing that rule (scale and rounding mode) on the total itself rather than leaving it to be inferred.

Every estimate reports a completeness state: COMPLETE (every counted line is priced), INCOMPLETE_UNPRICED (at least one counted line has no price), or EMPTY (there is nothing counted yet). The total field reflects that state directly rather than presenting a number that looks final when it isn't.

When nothing priced counts toward the estimate, total is null — not zero, not a partial sum presented as final. Whenever completeness is anything other than COMPLETE, the total is reported as PARTIAL: a real, currently-computable subtotal of what is priced so far, clearly not the final figure. The distinction between a genuinely complete total and a partial one in progress is structural, not a note in a report footer.

This distinction exists because a null or a zero-looking total is easy to mistake for 'nothing owed' rather than 'not yet knowable.' An adjuster or carrier reading an estimate needs to know, at a glance and without inspecting every line, whether the number in front of them is the finished figure or a work-in-progress subtotal that will still move. completeness and the PARTIAL/null total together answer that question without requiring a reader to cross-reference the line list first.

Overhead and profit is expressed as a percentage on the estimate and applied to the priced subtotal entirely on the server; the amount it produces is reported alongside the subtotal, not computed by whatever is reading the estimate. The server applies whatever percentage is saved on the estimate; the web application pre-fills 20%, which the professional can change.

Sales tax is a single rate the professional enters on the estimate for the loss jurisdiction. When a rate is set, the server applies it to the priced subtotal only — never to the overhead and profit amount — and the total reports tax_state: APPLIED with the tax_amount. When no rate is entered, the total reports tax_state: NOT_APPLIED and a tax_amount of null, an explicit statement that no tax was applied rather than an implied zero. The rate is never defaulted. What does not exist yet is a real sales-tax model: there is no taxable-base split, rate lookup or jurisdiction model yet, so the professional supplies the rate and decides what it applies to.

Every total is a replacement-cost figure. valuation_state reports RCV_ONLY_NOT_DEPRECIATED: PaxExact has not yet computed depreciation or an actual-cash-value figure for any line or total. Depreciation and ACV are planned, not built — a total today should be read as RCV, and only RCV.

All three of these — overhead and profit, tax, and valuation — are reported as explicit states on the total rather than folded silently into a single number. A reader who needs to know whether a given total already reflects tax, or whether it is a replacement-cost or depreciated figure, can answer that from the total block itself, without having to know PaxExact's current feature set from memory.

A total only reflects lines that have cleared human review. approval_state reports whether every line on the estimate has been reviewed (ALL_REVIEWED) or whether some are still pending (PENDING_REVIEW). Alongside the money figures, every total reports counted, priced, and unpriced line counts, so a reader can see not just the number but how many lines produced it and how many did not.

This is the same approval gate described in PaxExact's review methodology: a line that has not been approved does not count toward the total, regardless of whether it has a price attached.

Practically, this means a total can change for two different reasons that look similar from the outside but are not: a new price arriving on an already-approved line, or a previously unreviewed line clearing approval and joining the counted set for the first time. The line counts reported alongside the total (counted, priced, unpriced) let a reader tell which kind of change happened without re-reading every line.

Every total PaxExact returns carries a contract_version, currency, scale, and rounding rule alongside the numbers, specifically so a consumer can display the figures with confidence rather than re-deriving them. Recomputing a total client-side and expecting it to match risks silently disagreeing with the server over an edge case in rounding, completeness, or approval state that the client cannot see. The rule PaxExact publishes for every integrator is simple: display the API's figures; do not recompute them.

That rule is also what makes an estimate auditable across systems. If a carrier's system, a public adjuster's software, and PaxExact's own case file all display the same server-computed total rather than each recomputing their own version of it, a dispute over a figure becomes a question of which snapshot each party is looking at — a question with a clear answer — rather than a question of whose arithmetic is right.