Month-End Close Checklist for SaaS Finance Teams on Usage Billing

Usage-based pricing has turned month-end close into a different job than the one most SaaS finance teams were trained for. Revenue no longer arrives on a schedule; it accumulates continuously, in variable amounts, and can't be finalized until the metering period actually closes. That single fact reorders everything else in the close, from when reconciliation can start to how revenue gets recognized.

The scale of the shift is not subtle. Companies using some form of usage-based pricing went from about 30% in 2019 to roughly 85% by 2024. According to the 2025 Monetization Monitor, 59% of software companies expect usage-based revenue to grow as a share of total revenue this year, up 18% from 2023. Credit-based pricing, specifically, has taken off even faster: per Kyle Poyar's Growth Unhinged newsletter, the PricingSaaS 500 Index counted 79 companies offering credit-based pricing, up from 35 at the end of 2024, a 126% year-over-year jump. That means wallets, drawdowns, and prepaid balances are now live variables at close for a fast-growing share of finance teams, not an edge case handled by a spreadsheet footnote.

Three things make a generic close checklist unfit for this environment. Revenue completeness can't be confirmed until metered event data closes, and there's no equivalent of "did the invoice go out?" to lean on. Variable consideration under ASC 606 demands estimation and constraint logic that flat subscription revenue never required. And deferred revenue, prepaid credit balances, and already-recognized revenue can all sit on the same customer account at the same time. A checklist built for this world has to encode sequence dependencies, data validation gates, and recognition logic beyond a list of tasks with names and due dates next to them.

How ASC 606 and IFRS 15 treat metered revenue differently from subscriptions

ASC 606, issued by FASB in May 2014, governs US GAAP reporting. IFRS 15, effective January 1, 2018 and issued by the IASB, governs entities reporting under IFRS. Both run on the same five-step model: identify the contract, identify performance obligations, determine the transaction price, allocate that price across obligations, and recognize revenue as control transfers. KPMG's updated Handbook on Revenue for Software and SaaS, refreshed in December 2025, is a key reference for how the five steps actually apply to software and SaaS contracts.

The model itself doesn't struggle with usage billing so much as it demands more work to satisfy. Variable consideration is the core issue: usage charges require finance to estimate expected consumption and then apply a constraint, recognizing only the amount unlikely to trigger a significant revenue reversal later. That constraint applies continuously throughout the period, not just at month-end, because the estimate has to hold up as consumption data accumulates. Hybrid pricing adds another layer. A contract that bundles a subscription tier, prepaid credits, and consumption overages may have three different recognition timelines running inside one agreement.

Mid-contract changes make this worse before they make it better. An upgrade means additional revenue can only be recognized once the upgraded obligation is actually satisfied, not the moment the upgrade is signed. A downgrade can require unwinding previously recognized revenue and issuing customer credits, which then need their own tracking. None of this is hard to do once. It becomes hard when a hundred of these changes land in the same week, which is exactly what happens near quarter-end when sales teams push renewals and expansions through before the deadline.

There's an architecture lesson buried in all this that finance teams ignore at their own risk: raw usage events need to be stored separately from the pricing rules that turn them into revenue. When pricing changes, the historical data has to stay intact and auditable, untouched by the new rule set. Mixing billing logic into application code, so that a pricing change silently rewrites how old events get valued, creates an audit trail that doesn't hold up. Get any of this wrong and the failure isn't cosmetic: financial misstatements, damaged investor trust, regulatory exposure, and leadership making calls off a financial picture that's simply not accurate. That weight causes every item in the checklist that follows.

The pre-close gate: validating metered data before the sequence starts

Nothing downstream works if the metered event data producing it is incomplete, mis-attributed, or bleeding across period boundaries. If reconciliation starts before that data is validated, the work doesn't get skipped, it gets redone, usually under worse time pressure than the first attempt.

Before Day 1 even begins, a few things need to be true. The billing period has to be fully closed across every billing platform in use, with no metering windows still open somewhere. Every event ingestion pipeline needs confirmed delivery, no dropped events, no processing lag that lets usage spill into next period's numbers. CRM, billing, and accounting feeds all need to have run successfully and agree with each other. Closed-won deals, renewals, upgrades, downgrades, and churn all need to show up correctly in billing before anyone starts reconciling against it. Contract changes affecting revenue timing or service periods need review and documentation. And known exceptions need resolution now, not mid-close.

Analysis of common exception scenarios points to late or incomplete consumption data from the product as a recurring source of close delays. This gate exists specifically to catch that problem before it works its way into every subsequent step. Prior periods get locked before the sequence opens too, so a late change doesn't quietly rewrite a month that's already been reported.

The better finance teams treat this less like a checkpoint and more like an ongoing habit. Exception management happens all month, so the pre-close gate becomes confirmation of work already done rather than the first moment anyone notices a problem. Skipping that discipline means the revenue completeness checks scheduled for later in the close stop being validations. They turn into cleanup.

Days 1–2: locking cash and sub-ledgers as the foundation for everything downstream

Nothing reconciles until every sub-ledger and feed has posted: payroll, the expense platform, billing and AR, AP, corporate cards, all of it. Cash reconciliation goes first, because everything else downstream assumes cash is right. If balance-sheet work starts before that foundation is stable, it has to be redone once it settles.

Usage billing adds its own wrinkles here. Billing AR often mixes invoiced charges with accrued usage that's been consumed but not yet invoiced, and those two need separating before AR aging means anything. Prepaid credit balances drawn down during the period need to post correctly, reducing the liability and recognizing the matching revenue in the same motion. Companies that grew usage billing on top of an existing subscription business often run multiple billing codepaths at once, and this is the moment to confirm all of them have run and tie back to one source of truth.

Expense-report cutoffs get enforced now too, so a late submission doesn't force the period back open. For context on pace: APQC's benchmark data across roughly 2,300 organizations puts median close cycle time at about 6.4 calendar days, with top-quartile teams finishing in 4.8 days or fewer and bottom-quartile teams running past 10. That gap is process discipline, not better software, and Days 1 and 2 are where the discipline either holds or starts to crack. SaaS specifically splits along similar lines: the strongest teams close in 5 to 7 business days, growth-stage teams average 10 to 15, and this early phase does a lot to decide which group a company falls into.

Days 3–4: accruals for consumed-but-unbilled usage and cost matching

The matching principle says expenses belong to the period that earned them. For usage-billed products, that cuts both ways: revenue for services delivered but not yet invoiced needs accruing, and so does the cost of infrastructure consumed but not yet billed by vendors.

On the revenue side, this phase covers posting accrued revenue for usage that happened during the period but hasn't been invoiced yet, which is common when billing runs on a lag or cycle dates fall mid-period. It also means keeping unbilled usage clearly separated from deferred revenue and recognized revenue in the ledger, since conflating those three is a recurring source of audit questions. For credit-based models, finance needs to calculate how much of the prepaid balance got consumed during the period and recognize that portion as revenue, leaving the untouched balance in deferred revenue where it belongs.

Cost accruals carry more weight here than they used to. Bessemer Venture Partners' 2025 Cloud Index found AI-native SaaS companies spending 22% of revenue on compute, against 8% for traditional SaaS. At that ratio, an unaccrued infrastructure bill doesn't nudge gross margin, it distorts it. That means accruing for cloud compute, inference API costs, and GPU-minutes consumed but not yet invoiced by vendors, along with identifying any other supplier costs incurred but not yet billed and posting estimates with documentation to back them up.

Standard accruals still apply on top of all this: payroll, bonus accruals, PTO, amortization of prepaids like insurance and software, fixed-asset depreciation. Multi-entity teams need to reconcile intercompany balances before consolidation and tie every sub-ledger back to its GL control account before moving forward. Missing an accrual in this phase doesn't just look bad, it swings margin and forces a correction the following month, and at usage-billing infrastructure costs, that swing is bigger than it would be in a flat-rate business.

Days 5–6: revenue recognition, the deferred revenue waterfall, and variable consideration

The deferred revenue waterfall sits at the center of this phase. It has to roll cleanly from opening balance to closing balance, with every addition, every recognition event, every reclassification and adjustment accounted for, and the ending number has to tie to the deferred revenue line on the balance sheet. If it doesn't, something upstream didn't get captured.

The recognition work itself involves rolling that ASC 606 waterfall and recognizing the period's earned revenue, booking usage-based true-ups as variable consideration recognized as usage happens (not on the invoice date, not on payment receipt), and applying the constraint test to confirm the recognized amount won't trigger a significant reversal once final consumption numbers land. MRR and ARR need to be reconciled from the billing system all the way down to the GL revenue account, and any gap needs an explanation.

Credit-based models add their own steps. Revenue from prepaid credit sales gets recognized as credits are consumed, with the unearned portion sitting as a liability until then. Breakage, meaning credits purchased but never used, requires a documented policy applied consistently every period. The credit balance ledger needs to reconcile to the deferred revenue account at close.

Atlassian's pricing structure is a useful illustration of how tangled this can get on a single contract: a subscription tier, bundled AI entitlements (a set allotment of Rovo AI credits per user per month), and consumption overages charged per conversation beyond the included limit, all coexisting on one agreement. Each piece has its own recognition timing and needs allocation at its standalone selling price. Mid-contract changes get handled here too: upgrades recognize additional revenue only once the upgraded obligation is satisfied, downgrades require adjusting prior recognized revenue and managing any resulting credits, and every exception created by a mid-term change, cancellation, or non-standard term gets reviewed individually.

Stock-based compensation gets recorded under ASC 718, and sales and use tax gets accrued on taxable SaaS revenue. The two most audit-visible mistakes in this business both live in this phase: recognizing a full annual contract on the invoice date instead of ratably, and a deferred revenue waterfall that doesn't tie to the GL because prorations, cancellations, or mid-month changes never got captured. Both are catchable here. Neither is easily fixed later.

Days 7–8: cross-system reconciliation between billing data, CRM, and the general ledger

Three systems have to agree by the end of this phase. CRM contract values need to reconcile to billing outputs, confirming quantities, pricing tiers, and any modifications actually appear in what got billed. Billing outputs need to reconcile to accounting entries, so every invoice, credit note, and usage charge has a matching GL entry in the right account and period. And revenue movements need to line up with customer events: an expansion, a contraction, a churn event, a credit drawdown, each one needs a counterpart in every system it touches.

Usage billing adds specific checks on top of the standard three-way tie-out. Metered usage totals by customer need to match what billing actually invoiced; a mismatch usually points to either a metering gap or an error in a pricing rule. This reconciliation is also where discrepancies between expected and actual billing outputs become visible. Ordway Labs' analysis flags inaccurate proration calculations as one of the more common sources of close delays, and this is the point to confirm they've been caught and corrected. For credit-based models, the credit consumption ledger needs to match both the billing system's drawdown records and the GL's deferred revenue reduction.

P&L flux and variance review happens against budget and prior period, with anything over the materiality threshold getting investigated on the spot. Writing the variance explanation now, while the data is still fresh, keeps the reasoning attached to the numbers; reconstructing that reasoning a week later is where close time quietly evaporates. Finally, the controller reviews the full trial balance line by line, tracing every balance back to its support. This is the review that catches the entry booked to the wrong account, the accrual that looks slightly off, and the revenue number that doesn't hold up once someone actually checks the math behind it.