Revenue Recognition and AR Under ASC 606 for B2B Service Firms

ASC 606 moved the trigger for revenue recognition from "when the invoice went out" to "when the customer actually gets control of what you promised them." Before the standard, most companies booked revenue when risk of loss transferred, and in practice that meant billing day or the day cash hit the bank. That logic worked fine when the thing changing hands was a crate of widgets. It works a lot less fine when the thing changing hands is forty hours of a consultant's attention, spread across a month, with the invoice landing on the first and the actual work happening whenever it happens.

That's the specific problem for B2B service firms: professional services shops, consulting practices, managed service providers. Their product is continuous performance, delivered in a stream, while the billing cycle runs on its own separate clock, monthly retainer, milestone invoice, or time-and-materials cycle. None of those billing rhythms were built to track the pattern of actual work. So the invoice date and the "control has passed" date can drift apart, sometimes by weeks, and that drift is what creates the gap between recognized revenue and recorded receivables.

The fix FASB built for this is the five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate it, and recognize revenue as each obligation gets satisfied. KPMG's December 2025 Revenue Recognition Handbook makes a point of warning that this isn't a run-it-once-and-forget-it exercise. It calls for ongoing judgment, estimation, and disclosure, and new business practices keep generating new wrinkles for companies to work through. For a B2B service firm, that's the whole game: the five steps are where the judgment calls live, and those judgment calls are what eventually land, for better or worse, on the AR aging report.

How the five steps work for service contracts

Walking through the five steps with an actual service contract in mind, not a textbook example, reveals a pattern quickly: each step holds at least one decision point unique to service arrangements, and each of those decisions changes when revenue, and therefore receivables, get booked.

Step 1 is identifying the contract; the test under ASC 606-10-25-1 is whether collection of substantially all the consideration is probable. For a B2B service firm working with a large, creditworthy enterprise customer, that bar is usually cleared without much drama. It gets more complicated with early-stage customers or contracts that carry odd payment terms, where the firm needs to document, in writing, why it believes it'll actually get paid. Failing this step means there's no revenue to recognize. Any cash collected in the meantime sits on the balance sheet as a liability, not revenue, regardless of how much work has already been done.

Step 2, identifying performance obligations, is where bundled service contracts tend to come apart at the seams. The test is whether each piece of what's promised is capable of being distinct and distinct within the context of the contract. A managed-services deal that bundles onboarding, ongoing support, and monthly reporting might be one obligation or three; it depends on whether the customer could use each piece on its own. A firm can end up recognizing revenue before control of anything has transferred if it assumes every fixed-price milestone is a clean, separate obligation without checking the actual acceptance language.

Step 3 is setting the transaction price, which gets its own full section later in this piece, because for service firms this is where fees stop being fixed numbers and start becoming moving targets.

Step 4, allocating the transaction price across obligations, runs on standalone selling prices. When a service firm has custom, negotiated pricing, it usually has to estimate prices rather than pull them from a price list, and that allocation choice decides how much revenue sits behind each invoice milestone. It matters, but it's a quieter problem than Steps 3 and 5. It doesn't generate the same size of AR distortion on its own.

Step 5, recognizing revenue when or as the obligation is satisfied, is where the biggest fork in the road sits for service firms: over time, or at a single point in time. That single determination decides more about a firm's balance sheet than any other step in the model, and it's the subject of the next section.

The over-time vs. point-in-time determination's effect on your receivables ledger

Whether a service obligation gets recognized over time or all at once is decided by three specific criteria in ASC 606-10-25-27, not a preference a controller gets to pick, and any one of the three is enough to trigger over-time treatment.

Under criterion (a), the customer receives and consumes the benefit as the firm performs it, which is the standard case for recurring managed services, maintenance contracts, and ongoing support. Criterion (b) covers performance that builds or improves an asset the customer already controls as it's being built; construction on a customer's own land is the classic case. Criterion (c), the one that matters most for enterprise professional services firms, applies when the work creates something with no alternative use to the firm and the firm has an enforceable right to payment for work completed so far. That enforceability question turns on contract language and jurisdiction, not on whether an invoice happens to have gone out.

The "no alternative use" piece of criterion (c) trips firms up more than they expect. A standardized onboarding curriculum or a templated implementation process, the kind every customer gets, usually has alternative use by definition (it's the same playbook run over and over). That disqualifies criterion (c) even when the payment terms are airtight.

If none of the three criteria apply, or if criterion (c)'s payment condition fails, the obligation recognizes at a single point in time: whenever control of the finished output actually passes to the customer. For consulting work with real customer acceptance rights, revenue can wait until the client signs off, even if the work is already done to the last hour.

This is where the balance sheet consequences split into three distinct patterns. Over-time recognition that runs ahead of billing creates a contract asset, revenue earned but not yet invoiced. When billing runs ahead of recognition, it creates a contract liability, cash or invoices sent for work not yet performed. Point-in-time recognition held up by an acceptance clause creates nothing on the books until that acceptance event actually happens. You get three different mechanisms, three different aging profiles, three different sets of expectations for when cash actually arrives. Every AR report a service firm produces is downstream of this one determination.

Measuring progress for over-time obligations and the AR distortions caused by measurement errors

Once a firm lands on over-time recognition, it still has to decide how to measure progress, and that choice is not a technicality. Pick an input method versus an output method and get a different revenue number in any period where the work doesn't land evenly, because the method is supposed to reflect how performance actually happened, not just whichever number is easiest to pull from the system.

Output methods measure value delivered directly: milestones hit, units produced, work surveyed and confirmed. They fit contracts with clear, countable deliverables at each stage, but someone has to keep measuring against an external benchmark every period, and that takes ongoing effort.

Input methods measure resources used, labor hours, costs incurred, materials consumed, as a share of the total expected. For professional services firms, you track hours worked as a percentage of total hours expected, because it lines up directly with staffing plans and project budgets. Cost-to-cost measurement is more common in construction and other project-heavy industries, where materials and subcontractor costs dominate the cost structure.

Both methods break in the same way: when overruns don't represent real progress. If a project burns extra hours from scope creep nobody approved, those extra hours inflate the input-method percentage and pull revenue forward that hasn't actually been earned yet.

The percentage-complete number that comes out of this calculation sets the contract asset or liability balance directly. Earned more than billed, the firm carries a contract asset for the gap. Billed more than earned, it carries a contract liability. Neither one is a receivable yet; neither appears if the AR team is only looking at billed invoices. If you build an aging report only from billed receivables, you miss the contract asset balance behind it, revenue already earned that becomes a real receivable the moment the next invoice goes out. Collections planning and revenue forecasting can't really be separated from this measurement decision. They're reading the same number from two different angles.

Variable consideration: estimating it, constraining it, and the constraint's effect on billed AR

Variable consideration covers every dollar in a contract that isn't fixed at signing: success fees, usage-based pricing, retroactive volume discounts, performance bonuses, penalties, refunds. For B2B service firms, this is usually where the gap between what's recognized, what's billed, and what can actually be collected gets widest and hardest to track.

Two methods exist for estimating it. Expected value adds up every possible outcome weighted by probability, so it works best across a portfolio of similar contracts, where the law of averages has something to grab onto. Most-likely amount picks the single outcome you expect to happen, and it works best for binary outcomes, where a bonus either hits or it doesn't. Whichever method a firm picks, it has to apply it consistently and write down why.

Then comes the constraint: only count variable consideration where it's highly probable there won't be a significant reversal once the uncertainty clears up. That's not the same as waiting until the outcome is certain. You need to apply real judgment, backed by historical data, the actual contract terms, and what you know about the specific customer.

One past situation illustrates what happens when that judgment goes wrong. A usage-based SaaS client had been recognizing variable, usage-based fees without properly applying the constraint, counting revenue that hadn't yet cleared the "highly probable" bar. An audit flagged it. The fix required rebuilding the estimate using both methods, expected value and most-likely amount, run side by side and compared, and resulted in a material deferral of revenue that had been recognized too early. The lesson sits right there in the numbers: skip the constraint, and the audit finds it for you later, at a worse time and a bigger size.

The AR consequence of applying the constraint correctly cuts both ways. A success fee constrained to zero at signing, then triggered mid-engagement when the customer hits the milestone, gets recognized all at once in the period it resolves, sometimes as a contract asset, with no prior billing cycle behind it to explain the jump. Collections teams need a heads-up before that number appears, not after. Retroactive volume tiers create the opposite headache: a firm with pricing that drops at higher volumes has to re-estimate the full contract price every reporting period and true it up. If that true-up shrinks previously recognized revenue, the contract asset shrinks with it, but the invoice already sent to the customer can't just be unilaterally revised downward. That's a conversation with the customer, not a journal entry alone.

The right-to-invoice practical expedient: applicability and limits for simplifying AR

The right-to-invoice practical expedient is the closest thing ASC 606 offers to a straight line between billing and revenue recognition. It lets a firm recognize revenue equal to whatever amount it has the right to invoice, as long as that invoice amount directly matches the value of the work performed so far. A time-and-materials contract billed at agreed hourly rates for hours actually worked is the textbook fit, and it's effectively built for T&M service arrangements, where the invoice already represents the value delivered in that period.

The decision rule is simple. Ask whether the billing arrangement lines up, period by period, with the value of work performed in that same period. If it does, the expedient applies, and the AR picture gets dramatically simpler: the invoice becomes the receivable the moment it's issued, there's no contract asset, no contract liability, and the aging report tells the whole story of earned-but-uncollected revenue on its own.

If it doesn't line up, the firm is back in contract-asset and contract-liability territory, tracking the gap manually. Fixed-fee contracts billed in equal monthly installments rarely match the actual pattern of work; front-loaded delivery billed in flat tranches produces a contract asset early and a contract liability later, with the invoice schedule telling a different story than the work schedule. Capped T&M arrangements run into the same wall: once billed hours hit a not-to-exceed ceiling, the invoice stops representing the real value of hours worked, and the expedient no longer applies for that stretch. Retainers with scope that varies month to month have the same problem if the flat retainer fee stops tracking what's actually getting delivered.

Firms using the expedient are exempt from disclosing the transaction price allocated to remaining performance obligations, a relief that applies to any obligation satisfied under the expedient, not just contracts with variable pricing attached. For T&M-heavy service firms, that means one less disclosure schedule to maintain every reporting period.

Contract assets vs. accounts receivable: the balance sheet distinction that changes how AR is managed

Everything in the preceding sections funnels into one structural line on the balance sheet: the split between a contract asset and an accounts receivable. The two look similar from a distance, both represent money a firm expects to collect, but they carry different legal footing, and treating them as interchangeable creates real problems for both financial reporting and day-to-day collections.

A receivable is unconditional. The firm has billed the customer, the invoice is out, and the only thing standing between the firm and cash is the customer actually paying. A contract asset is conditional. Revenue has been earned under the over-time or measurement rules covered earlier, but no invoice has gone out yet. The amount depends on something besides the customer's willingness to pay. It depends on the firm completing a future milestone, reaching a billing date, or clearing whatever condition the contract attaches to invoicing.

That distinction changes how collections teams should actually operate. A receivable belongs on a traditional aging schedule, with reminders, follow-ups, and escalation paths tied to invoice date. A contract asset isn't collectible in that same sense, because there's nothing to collect on; it's a forward-looking number that tells a finance team what's about to become a receivable, once the next billing trigger fires. Collections and forecasting teams that only watch the AR aging report are missing half the picture: the contract asset balance is the preview of next month's invoices, sitting right there in the revenue recognition entries, waiting for the billing cycle to catch up to the work that's already been done.