Your FOCUS cost dashboard disagrees with the invoice. How do you reconcile it without hiding commitment waste?

TL;DR: Reconcile invoices with BilledCost, grouped by issuer, invoice, account and billing currency. Use EffectiveCost for amortized analysis, preserving unused commitments and corrections. Keep currencies separate until an explicit conversion step. A common schema makes these distinctions queryable; it does not make every export complete or every total comparable.

How to approach it

Ask which invoice and dataset revision finance is comparing, whether the billing period is closed, and which cost column the dashboard sums. Then inspect credits, corrections and commitment purchases before assuming that resources are missing. State the schema version: this example uses the published FOCUS 1.2 specification.

A strong answer

Choose the accounting question. BilledCost includes negotiated rates and discounts but does not spread an upfront purchase across its future usage. FOCUS 1.2 requires its sum for an invoice to match that invoice's payable amount. EffectiveCost distributes applicable prepaid costs to the charges they cover; the original prepaid purchase has zero effective cost to avoid counting it twice. These are separate measures, so adding them creates a meaningless total. See the definitions of Billed Cost and Effective Cost.

Consider this synthetic exercise, a summary of selected FOCUS columns. One issuer bills account A in USD. Its closed September invoice has no tax, support fees or other charges beyond these rows. A $1,200 prepaid commitment starts this month; assume its schedule allocates exactly $100 to September, of which $80 was consumed and $20 unused. The refund corrects an August on-demand charge and appears on the September invoice.

The invoice reconciles to 1,200 + 40 - 10 - 5 = $1,225. The exported rows' effective total is 80 + 20 + 40 - 10 - 5 = $125. The $1,100 difference is prepaid cost allocated to later periods; it is not savings. The unused $20 remains a cost even though no workload consumed it. Retain the commitment ID and CommitmentDiscountStatus so allocation does not silently drop that waste.

For September operations, show $140 before promotional credits and the prior-period correction. Separately show the $10 credit and assign the $5 refund to the corrected period in an explicitly restated trend. That policy yields $130 for September after its credit; it does not change the $1,225 invoice reconciliation. Preserve both the original and restated reports. ChargeClass identifies corrections to previously invoiced periods; a negative value alone does not tell you whether a row is a refund, credit or reversal.

Prove scope before conversion. Suppose another account has INR 1,000 billed for the same month. Report USD 1,225 and INR 1,000 separately. BillingCurrency identifies the invoice currency; matching column names do not make unlike currencies additive. For a management total, use finance's documented exchange-rate source, date and rounding rule, keep the original values, and label the converted measure. Never overwrite source costs with converted amounts.

Investigate the remaining difference. Group billed rows by InvoiceIssuer, InvoiceId, BillingAccountId, BillingCurrency and billing period. Sum all groups belonging to the invoice, including corrections for earlier periods; filtering only September usage would lose them. Check missing files, overlapping export revisions, late adjustments and marketplace invoices. Account for taxes and support if present in the real invoice. An incomplete export may need a documented reconciliation bridge; do not invent an adjustment row just to force equality. Preserve source-file identity and ingestion version so reruns do not double count the month.

What interviewers probe next

"Can I remove every negative row to make the dashboard easier to read?" That would overstate the bill. Keep the signed rows and expose a separate operational view whose exclusions are named and reversible.

"The dashboard is correct today and wrong tomorrow?" Check whether the provider replaced provisional data or issued a correction. Ingest revisions idempotently, record the data's timestamp, and rerun reconciliation before marking a period final.

"Does a passing FOCUS validator prove our total is correct?" It checks the rules it implements for that version. Also compare source totals, invoice totals and export coverage; structurally valid data can still be an incomplete delivery.

Common mistakes

Adding purchase BilledCost to usage EffectiveCost, charging the same commitment twice.

Allocating only rows with a resource ID and losing unused commitments or account-level charges.

Calling a promotional credit an engineering efficiency improvement, or combining currencies before recording an exchange-rate policy.