AI outcome-billing reconciliation worksheet
Join billed AI events to customer issues, test the actual contract definition, and separate invoice correctness from customer resolution in one reviewable ledger.
A billable outcome and a solved customer problem are two claims. Test each against its own evidence. A charge can match the agreement while the customer still needs help; a customer can receive good help while an invoice contains a duplicate.
Use this worksheet after purchase, alongside the AI vendor RFP used before purchase. It creates a record finance and support can inspect together. It does not decide what your contract means or promise a credit.
1. Establish the review
Assign a finance owner for contractual interpretation and payment handling, a support owner for customer outcomes, and a data owner for exports. Preserve the original invoice and export; work on a copy. Use approved internal identifiers rather than copying customer messages into a broadly shared spreadsheet.
| Review field | Fill in |
|---|---|
| Provider, product and account | [names / account reference] |
| Invoice and billing period | [reference / start / end / timezone] |
| Currency and tax treatment | [currency / included or separate] |
| Agreement and effective version | [approved document / date] |
| Billable trigger and exclusions | [exact clause references] |
| Reopen, transfer and duplicate treatment | [contract rules / unresolved interpretation] |
| Support outcome definition | [evidence required / observation window] |
| Event export and completeness | [location / row count / missing fields] |
| Review scope | [all events or sampling method / limitations] |
| Owners and next review | [finance / support / data / date] |
If the agreement is ambiguous, mark the interpretation unresolved and take it to the contract owner. Do not rewrite the agreement in a spreadsheet.
2. Copy the event ledger
One row represents a billed event, not necessarily one customer issue. Several events can belong to the same issue. Retain that relationship instead of deduplicating away evidence.
| Invoice line / event ID | Customer issue ID | Event time | Amount / currency | Contract trigger evidence | Billing finding | Outcome evidence / observation ends | Outcome finding |
|---|---|---|---|---|---|---|---|
| [line / event] | [approved reference] | [timestamp + zone] | [amount] | [clause + record] | [supported / candidate discrepancy / unknown] | [record + date] | [confirmed / unresolved / unknown / still observing] |
Add an action record for every candidate discrepancy or unknown:
| Event ID | Question or discrepancy | Evidence still needed | Owner | Due / next update | Disposition and evidence |
|---|---|---|---|---|---|
| [event] | [duplicate / rule mismatch / missing evidence] | [export / clarification] | [person] | [timestamp] | [accepted / corrected / unresolved + record] |
“Unknown” is a valid finding. Silence, an ended session and a missing link are not interchangeable evidence of success.
3. Reconcile before summarizing
- Match event IDs and totals to the invoice. Explain missing periods, repeated exports and adjustments before reviewing outcomes.
- Separate usage charges, minimum commitments, platform fees, credits, discounts, taxes and currency effects. Do not force the event ledger to explain unrelated invoice lines.
- Check the agreement's actual trigger, exclusions and observation rules for each reviewed event.
- Review customer outcomes independently, including recontacts through another channel where approved records allow linking.
- Report reviewed events, distinct issues, supported amounts, candidate discrepancies and unknowns separately. A credit is only received when there is evidence of it.
If you sample events, record how they were selected. A targeted sample of suspicious charges helps investigate failures; its discrepancy rate cannot be presented as the rate for the whole invoice.
4. Fictional worked example
All IDs, amounts and contract rules below are invented. The example agreement charges one billing unit per distinct issue with customer-confirmed completion; it excludes duplicates, human transfers and reopens inside its observation window. These are not any vendor's terms.
| Event | Issue | Billed units | Observed evidence | Billing finding | Customer outcome |
|---|---|---|---|---|---|
| E01 | A | 1 | Confirmed completion, window elapsed | Supported | Confirmed |
| E02 | A | 1 | Duplicate of E01 | Candidate discrepancy | Same issue, already counted |
| E03 | B | 1 | Customer silent; no confirmation | Candidate discrepancy | Unknown |
| E04 | C | 1 | Human completed the task after transfer | Candidate discrepancy | Confirmed human resolution |
| E05 | D | 1 | Reopened inside the agreed window | Candidate discrepancy | Unresolved |
| E06 | E | 1 | Customer record unavailable | Unknown | Unknown |
Six billed units cover five distinct issues. One unit is supported, four are candidate discrepancies and one remains unknown. That does not mean four units have been refunded. The action is to supply the four event records to the finance owner and recover the missing evidence for E06.
5. Close the review
Write a short decision: [pay/process under the approved finance workflow], [investigate these event IDs], [request this clarification], and [change this operational measurement]. Name the owner and date for each. Keep invoice correction separate from customer recovery so neither waits for the other unnecessarily.
Repeat after a material contract change or unexpected billing pattern. Use the record to improve the next purchasing conversation rather than treating one month's sample as a universal vendor ranking.
Sources and limits
The FinOps Foundation's invoicing and chargeback guidance supports validating technology invoices, credits and rates with finance. This support-specific ledger is an original editorial worksheet, not a FinOps certification or an accounting standard. The metrics dictionary helps document the separate outcome definitions. Prices, entitlement to credits, tax and payment decisions come from your current agreement and accountable finance team.
Continue exploring