The provider's data gets things wrong too
It is easy to assume the billing export is the truth. It is accurate in the total, but in the detail it brings situations that lead to wrong conclusions if they are not handled. These are not rare faults: they show up in almost any organisation with a minimum of volume.
The most common problems
Duplicate rows. Some exports are regenerated during the month or at closing, and if the loading process does not account for that, the same consumption appears twice. The period total stops matching the bill.
Badly spread commitments. A savings plan or a reservation generates the purchase on one side and the covered usage on the other. If they are not correctly related, the benefit of the discount is allocated to the wrong party, or the purchase shows up as one enormous one-off expense.
Misclassified charges. Taxes, credits, support or adjustments mixed in with consumption. Adding it all together inflates or reduces the cost of services that have nothing to do with it.
Changes of meaning. A field the provider redefines, or a new version of the format. The pipeline carries on working, but the numbers change meaning without warning.
Four corrections, in order
- Deduplicate. Define what uniquely identifies a row and keep the most recent version of each one.
- Spread commitments. Amortise each purchase across its term and allocate the benefit to the usage it actually covered.
- Reclassify charges. Separate consumption from taxes, credits, support and adjustments, so that each analysis adds up what it should.
- Reconcile. Compare the corrected total with the bill for the period. If the difference exceeds an agreed threshold, the process stops and raises an alert.
How to keep it healthy
- Every correction is a written rule, with its reason and an example of the situation it corrects. No manual tweaks in a spreadsheet.
- Measure what you correct: how many rows were deduplicated, how much cost was reclassified. If those numbers spike one month, something changed at the source.
- Reconciliation is the approval gate. Data that does not match the bill is not published, even if that delays the report.
The underlying rule is simple: data corrected with visible rules is worth more than data delivered fast. The first can be defended in front of finance; the second cannot.
How we apply it: FinOps Engineering.