ACV Calculation and Correction
Status: On request. A Data Enhancement operation. Writes to the CRM.
What it does
Annual contract value is not stored anywhere directly. The contract exists across line items, billing periods, dates and terms, while reporting needs one figure. This operation recomputes ACV from the line items actually attached to a deal, allocates it across year buckets, and writes the result back to the deal. Where the stored figure has drifted from what the line items support, the deal is corrected.
It is arithmetic, not inference
Every figure comes from dates and amounts already on the records. No part of this calls a language model, and nothing is estimated: the same deal and the same line items produce the same result on every run. Once an organisation has defined how ACV is calculated, there is no reason for that definition to be reinterpreted per deal.
Four calculation models
Two questions are independent of each other: whether value is recognised when it is booked or spread across the days it covers, and whether a year means a calendar year or your financial year. Answering both gives four models, and all four are computed in the same run rather than chosen between.
Booked, calendar year. The booked value bucketed by the calendar year of the line item start date and spread across the term.
Booked, fiscal year. The same booked value allocated into fiscal-year boundaries.
Prorata, calendar year. A daily rate derived from the annualised value, allocated across calendar-year segments.
Prorata, fiscal year. The same daily allocation bucketed into fiscal years.
Calendar and fiscal years are handled separately
The fiscal year start month is configuration, set per deployment rather than assumed. If your financial year does not begin in January, the calendar-year figure and the fiscal-year figure are genuinely different numbers, and both are written so reporting does not have to reconcile them afterwards. A readable fiscal-year label is stored alongside the figures so a reader can see which boundary produced them. Leap days are handled explicitly in the daily allocation rather than approximated.
Line item inputs
The calculation reads the recurring billing fields on each associated line item: the billing start date, the billing period or frequency, the term in months, and the number of payments, with the generic billing start and end dates used where the recurring fields are absent. Value comes from price and quantity, with discounts applied whether they are expressed as a percentage or as a currency amount.
A line item without a usable start date or price is not guessed at. It is skipped, and the deal is computed from the line items that can be read.
Close date propagation
The deal close date is copied onto the line items associated with that deal, so line-item level reporting can be filtered on the same date the deal uses. The write is schema-guarded: in a portal where that property is not present on line items, the step is skipped rather than failing the run.
What is written back
Each model writes a corrected summary value and its year buckets: a booked calendar summary and buckets, a booked fiscal summary and buckets with the fiscal-year label, and the two prorata equivalents. Summary values are computed from the reconciled, rounded buckets, so the summary and the buckets agree rather than being calculated independently.
Year buckets currently span 2025 to 2030. That range is fixed in the implementation, not open-ended: extending it is a code change, and value falling outside the range is not silently dropped into an adjacent year.
When a recalculation runs
Recalculation is triggered by a CRM webhook when a deal or an associated line item changes. The request signature is validated before anything is processed, the webhook is acknowledged immediately, and the recalculation runs after the response so that a slow calculation cannot cause the CRM to retry or throttle the endpoint. Events arriving for several deals in one payload are resolved to a distinct set of deals before any work begins.
Schema guards
Property schemas are cached per portal, and a write payload is filtered to the properties that actually exist there. A missing property is logged and skipped rather than failing the deal, which means a portal can deploy only the models it needs: a customer using calendar-year figures alone does not have to create the fiscal properties to run the operation.
Configuration
The fiscal year start month, the property names each model writes to, and which models a portal deploys are all configured per deployment. Nothing here is a Mixbound default imposed on a customer: a February fiscal start and a January one are the same operation with different configuration.
Operational considerations
This operation writes to deals and to line items, so it is deployed deliberately rather than left running. It holds its own credential scoped to the portal it serves and does not borrow another service's access. A recalculation is a full recomputation from the line items rather than an incremental adjustment, so a repeated run over an unchanged deal produces the same values it produced before.