How do QoE teams test SSP allocation on a contract sample?

In a quality of earnings (QoE) review of a SaaS target, revenue quality usually comes down to contracts. Billings say little until someone recomputes, contract by contract, how each price was allocated and spread over the term. This guide is for transaction advisory and financial due diligence teams. It covers picking a sample, re-performing the relative standalone selling price (SSP) allocation and schedule, comparing the result with the target's revenue by period and deferred revenue, documenting each difference with its clause, and where the work stops. For the rounding mechanics behind a schedule that ties to the cent, see our residual-cent post.

Why does SaaS revenue quality hinge on contract-level recomputation?

Because reported SaaS revenue is the output of three judgements made per contract: how the price was allocated across obligations, how ratable revenue was spread over the term, and where the cutoff fell. A misallocated implementation fee, or ratable revenue started a month early, moves revenue between periods and changes the deferred balance a buyer inherits.

Under ASC 606-10-32-28 to 32-41, the transaction price is allocated to each performance obligation in proportion to its standalone selling price. Recognising that allocation over time creates the contract liability (deferred revenue) presented under ASC 606-10-45-1 to 45-2. If the allocation is off, every later period is off too.

How does a deal team select a sample of contracts?

Most teams combine coverage and risk: the largest contracts by annual value, plus contracts with bundled obligations, non-standard terms, large discounts or signing dates near period end. The sample has to be big enough to support a view on the population and small enough to re-perform properly in the diligence window.

Bundles of subscription, implementation and support deserve extra weight, because allocation errors live there; so do late-period signings, where ratable revenue cutoff slips.

How do you recompute the allocation and schedule for each sampled contract?

For each sampled contract, confirm the performance obligations, the stated prices, the SSP basis and the term. Then allocate the transaction price on a relative-SSP basis, build the full-term schedule, and compare revenue by period and the deferred balance at the cutoff date with the figures in the target's ledger.

Take one contract in the sample: a $100,000 transaction price with three obligations whose SSPs are $30,000, $30,000 and $120,000.

Rounding each line independently gives $100,000.01; assigning the residual cent by a fixed rule ties the allocation to the price. The schedule works the same way: a $100,000 ratable amount over 36 months schedules as 35 × $2,777.77 plus a final month of $2,778.05, exactly $100,000.00, so deferred revenue ends at $0.00. You can re-perform the allocation with the SSP allocation calculator.

How should differences be documented?

Each difference between the recomputed figures and the target's ledger goes on an exceptions list with the contract, the period, the amount and the cause. Attach the clause evidence: the contract page and the verbatim excerpt that sets the obligation, price or term. A reviewer can then trace the difference without reopening the data room.

In the Soluqube app, uploaded text-layer PDFs also show a highlight on the cited line; the exported workpaper carries the page and excerpt. Scanned PDFs without a text layer are not accepted, and the built-in samples use an approximate overlay.

Common causes: a different SSP basis, an implementation fee recognised up front, a start date that differs from the contract, or an amendment the ledger reflects but the sampled document does not.

What does a deterministic, hashed workpaper add to the data-room evidence?

It makes the recomputation re-runnable. When the allocation and schedule are computed in integer arithmetic and exported with a SHA-256 hash, anyone with the same inputs gets byte-identical output. The buyer or the target's team can re-run a disputed contract and compare the hash, instead of arguing over whose spreadsheet is right.

Opaque tools fail that test; see why finance teams reject black-box AI.

What does contract-level recomputation not cover?

It is a calculation and evidence trail, not a QoE opinion. SSP judgements, normalisation adjustments and the conclusions in the report stay with the deal team. Contract modifications are flagged, not accounted for, and usage-based fees are not scheduled. The extraction of contract terms is a starting point that a person confirms.

Recomputation also cannot fix the data quality of the target's own ledger; it shows where the ledger and the contracts disagree.

How can you run it on your next deal?

The QoE Deal Pack covers up to 25 contracts per deal, delivered within 5 business days: relative-SSP allocation per obligation, full-term schedules that tie to the cent, and a SHA-256 hashed evidence workbook per contract. It is $1,750 per deal, a founding price for the first 10 customers. You confirm the obligations and SSPs used.

The list price is $3,500; see pricing. Want to see it first? Request a free 3-contract workpaper on three contracts of your choice.