Loading article…
Loading article…
Last updated on Sep 13, 2026
Every contract in Maxio Core already has a revenue schedule. What Advanced Revenue adds is the step before scheduling: deciding how much of the contract price each performance obligation actually earned, independent of what the invoice line says. That decision is what ASC 606 asks for, it is what an auditor will test, and it changes the month in which revenue lands. This article explains why that matters and when to reach for each of the allocation levers — then points you to the worked examples and configuration references for the details.
Advanced Revenue is a Maxio feature that lets you re-allocate revenue across your contract population using flexible, fixed, and dynamic formulas.
Advanced Revenue is a Maxio Core add-on. If you are still deciding whether it fits your policy, see Determine if RevenueBooks Meets Your ASC 606 Requirements.
A contract's line items tell you what you billed. They do not tell you what each item is worth on its own — and under ASC 606, revenue is recognized on that standalone value, not on the price a salesperson happened to put on the line. When items in the same contract recognize on different schedules, that difference moves revenue between months.
Consider a $12,000 contract with two items: a $9,000 annual subscription recognized evenly over 12 months, and $3,000 of training recognized when it is delivered in month one. Taken at invoice value, month one recognizes $3,000 of training plus $750 of subscription. Now suppose your standalone selling prices say the training is really worth $5,000 and the subscription $10,000. Allocating the $12,000 on that basis gives training $4,000 and the subscription $8,000 — so month one recognizes $4,000 plus $667, and every later month recognizes $667 instead of $750. Same contract, same cash, roughly $900 more revenue in month one and correspondingly less across the rest of the year. Neither number is a rounding difference to an auditor.
Advanced Revenue does that reallocation for your whole contract population, using rules you define once in a Standalone Selling Price (SSP) List and attach to contracts through a RevenueBook. Each item in the contract becomes a performance obligation (POB) with its own allocated revenue, recognition method, and duration. See Understand RevenueBooks for how the pieces fit together.
The core question an SSP List answers is "what would this item sell for on its own?" When you can answer that for every item — from your price list, from observable standalone sales, or from an estimate your policy supports — set each entry's Allocate Revenue By to SSP Formula, and Advanced Revenue allocates the contract price across the items in proportion to their standalone values. That is the relative standalone selling price method ASC 606 expects as the default, applied automatically to every contract the list governs.
The standalone value itself does not have to be a single number. It can be a fixed amount, a quantity-tiered amount for items whose standalone price depends on volume, or a formula built from the item's list price, quantity, term length, the contract's totals, and numeric custom fields — including conditional logic, so one entry can express a policy such as "allocate on list price only above a threshold." That flexibility is what lets a single SSP List cover a whole catalog instead of one entry per price point. The results are always in balance: allocated revenue across a contract's obligations sums exactly to the contract price.
See Standalone Selling Price ("SSP") in Apply Allocation Methods to Contract Items for the calculation and the formula variables, and Examples A and E in Advanced Revenue Allocation Scenarios for fixed, tiered, and formula-driven SSPs.
Some items have no dependable standalone price: a platform fee that is discounted differently on every deal, or a bundled service you have sold at wildly different prices. ASC 606 still requires you to estimate a standalone selling price for those items, and it permits the residual approach only in a narrow case — when the item's standalone price is highly variable or uncertain, and the other items in the contract have observable standalone prices. It is not a shortcut for "this item never sells alone"; if you can estimate the price by another method, such as adjusted market assessment or expected cost plus margin, that is what the standard expects. Confirm with your accounting policy or auditor which items qualify before configuring them this way.
For the items that do qualify, set their entries to Contract Residual Amount. Advanced Revenue allocates the items with defined standalone prices first — the SSP Formula items and any Amount After Carve Outs items — and gives the remainder to the residual items. Two settings on the SSP List shape that remainder. Base Contract Residual SSP (when enabled for your account) chooses whether the residual is measured against the contract's total amount or its total list price. Residual Allocation for Multiple Performance Obligations decides how the remainder is split when more than one item is residual: by each item's sale price, list price, or amount after carve-outs. If the defined standalone prices ever exceed the base, the residual goes negative and Maxio flags the contract so you can correct the list rather than publish a distorted schedule.
See Contract Residual Amount for the calculation, and Examples C and D.2 in the scenarios catalog.
The hardest ASC 606 cases are obligations that exist in the contract but not on any invoice line: the free onboarding bundled into a subscription, the first-year support folded into a license price. Those are still performance obligations, and revenue has to be allocated to them.
A carve-out creates that obligation from an item you did invoice. On an SSP List entry, carve out a Percentage, a Fixed Amount (optionally per currency, so a fixed carve-out can differ for USD and EUR contracts), or a Formula from the source item, and Advanced Revenue splits the source line into two obligations before any allocation runs — the carved-out obligation and the remainder, which then goes through its normal allocation. Carved-out items can carry their own entries and carve-outs, so one line can fan out into several obligations, each with its own recognition method — which is how a single invoiced item can recognize part immediately and part ratably.
See Amount After Carve Outs ("AACO") for the mechanics and Examples B and F in the scenarios catalog, including allocating one item across multiple obligations.
Not every item should float with the allocation. Pass-through hardware, a third-party fee, or a line whose contractual price is its standalone price should be allocated exactly what it was sold for. Setting an entry to Amount After Carve Outs does that: the item takes its invoiced amount (less any carve-outs), it is removed from the allocation pool, and the remaining items share what is left.
This is also the behavior an item gets when it has no entry on the SSP List at all — and when a contract has no SSP List. That default is safe, but it means a catalog item you forgot to add to the list will quietly be treated as "worth exactly its invoice price," which is not what an auditor expects for a discounted bundle. Review the SSP List whenever you add items to the catalog. See Example D.1 in the scenarios catalog for SSP and Amount After Carve Outs working together on one contract.
Allocation rarely needs one flat rule for every deal. Conditional rules let one SSP List behave differently based on a transaction's attributes — amount, product family, item type, term length, or a custom field — so a large enterprise contract can use a quantity-weighted formula while smaller deals use the standard one, and each application is logged for audit. See Set Conditional Rules for Revenue Reallocation.
At the portfolio level, a contract can carry more than one RevenueBook, each with its own SSP List, with a Main Revenue Book controlling what Maxio shows by default. That lets you run an alternative allocation policy alongside your primary one — to test a change before adopting it, or to keep a second basis for a different reporting need — without touching the book your financials depend on. See Create and Configure RevenueBooks.
Because allocation moves revenue between transactions on purpose, a transaction's revenue will no longer equal its invoice. Advanced Revenue expects that: the Permit Imbalance Checks Only at Contract Level setting keeps the balance check where it belongs — the contract still has to tie out — and Review and Resolve Revenue Issues surfaces the contracts that don't.
To set up the pieces described here, see Create and Manage SSP Lists, SSP List Fields Reference, and Assign SSP Lists to Contracts.
Allocation decides how much revenue each obligation gets; the recognition method decides when. For the timing half, see Choose the Right Revenue Recognition Method.
Still need help?
Reach out and our support team will take it from here.