A recurring and frankly concerning pattern has emerged across the last three quarterly true-up invoices from our primary observability vendor, which I will not name directly but whose platform rhymes with "DataDog." As a team lead responsible for both our SRE practices and the associated budget, I have conducted a detailed forensic analysis of our committed contract versus the invoiced amounts, and I have identified systematic discrepancies that appear to be rooted in their calculation logic for overage.
The core issue revolves around the pro-ration mechanism for new seats added mid-period and the subsequent true-up. Our contract stipulates a base commit for 25 seats. In Q2, we onboarded 5 new engineers on the 15th of a 30-day month, logically requiring a 50% pro-ration for that month's overage. However, the true-up invoice calculated the overage for those seats as if they were active for the entire month, effectively double-charging for the first half. The variance was not trivial, amounting to a significant percentage of the quarterly true-up.
I have since reviewed this against their own published billing guidelines and cross-referenced with our usage export data (the `usage.by_product` API endpoint), and the numbers do not align. The methodology seems to be:
* **Claimed Vendor Calculation:** (Total Monthly Host Hours / 730) * List Price, with no apparent mid-month adjustment for net new seats.
* **Actual Contractual Obligation (per our understanding):** ((Pre-existing Overage Hours / 730) * List Price) + ((New Seat Overage Hours / 730) * List Price * (Days Active / Month Days)).
This has led me to a broader set of questions for the community, which I suspect may be affecting others on enterprise or team-tier plans with dynamic headcount.
* Has anyone independently audited their true-up invoices and found similar inconsistencies, particularly related to mid-period seat additions or deletions?
* Are there specific clauses in your Master Service Agreement (MSA) or Order Forms that you have had to explicitly define to lock down the pro-ration formula?
* What has been your experience with the vendor's finance operations team when disputing these charges? In our case, the resolution required escalating through our account executive and took two billing cycles to correct, with no compensation for the time value of the overpayment.
* Is this potentially a systemic issue with how their billing platform aggregates usage before applying contractual terms, or simply an error localized to our account?
Given the substantial annual spend involved in these platforms, an error of even a few percentage points translates to thousands of dollars in either lost capital or administrative overhead to rectify. I am compiling a more comprehensive analysis, but initial findings suggest a need for rigorous, ongoing invoice validation rather than trusting the generated invoice at face value.
— Billy
Oh wow, that pro-ration detail is super sneaky. I wouldn't have even thought to check the mid-month timing like that.
We've had smaller issues with our true-ups, but mostly around them counting inactive user accounts. Your example makes me wonder if we've got similar pro-rating problems. How did you even catch it? Was the line item description clear, or did you have to match dates from the usage export manually?