How to build a revenue recognition feed

What matters here

• Start from the contract, not the invoice. Billing and recognition are different events that rarely correspond.
• Record the allocation inputs. An auditor asks how a figure was derived, and a spreadsheet formula is not an answer.
• Generate schedules per obligation. One contract can hold several with different patterns and dates.
• A modification is a new allocation, not an adjustment. Getting that wrong is a restatement.
• Reconcile bookings to billings to revenue every period, and explain the differences rather than plugging them.

Who this is for

You run revenue accounting or finance systems. Recognition runs from a spreadsheet, the allocation logic lives in somebody's head, and each audit is a reconstruction exercise.

How it works in practice

The path from a contract being signed to revenue being recognised correctly.

1. 1

   Performance obligations come from the contract

   Each distinct promise, with its own delivery pattern, not a line on an invoice.

2. 2

   Standalone selling prices are applied

   From a maintained table, with the basis recorded per allocation.

3. 3

   The transaction price is allocated across obligations

   Proportionally, with every input stored for reconstruction.

4. 4

   A schedule is generated per obligation

   Ratable over term, at a point in time, or on usage, each with its own dates.

5. 5

   Modifications trigger a new allocation

   Prospective or cumulative catch-up per the standard, never an ad hoc adjustment.

6. 6

   Bookings, billings and revenue reconcile every period

   With deferred revenue explained rather than balanced.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   First, take obligations from the contract

   An invoice is a billing event, not an accounting one.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Salesforce CPQ and
   NetSuite, or whatever we run in those seats.
   
   I need contract line items with products, quantities, prices and term
   dates, and from the ERP the revenue arrangement and schedule objects.
   
   Extract performance obligations from the contract, not from invoices:
   each distinct promise, its delivery pattern, its start and end, and
   whether it is delivered over time or at a point in time.
   
   A twelve month subscription invoiced annually in advance is one
   obligation recognised over twelve months and one invoice. A professional
   services engagement invoiced monthly might be one obligation recognised
   on completion. Starting from the invoice gets both wrong.

2. 2

   Allocate against standalone prices, and record the working

   An auditor asks how the figure was derived.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. Hold standalone selling prices as a versioned table
   with the basis for each: observed price, adjusted market assessment, or
   cost plus margin.
   
   Allocate the transaction price across obligations in proportion to
   standalone price, and store on every allocation: which prices were used,
   which version of the table, the resulting percentages, and the amount
   allocated per obligation.
   
   Handle a discount deliberately. Where it is not attributable to a
   specific obligation, allocate it proportionally, and where the contract
   says otherwise, follow the contract and record that it did.
   
   The stored working is the point. Recomputing an allocation two years
   later against today prices produces a different number, and being unable
   to reproduce the original is what turns an audit question into a
   finding.

   Version the price table. Allocations are computed against the table as it was, and without versioning the whole history becomes irreproducible.

3. 3

   Generate a schedule per obligation

   One contract routinely holds several with different patterns.

   Copy

   Generate a schedule per obligation rather than per contract:
   
     Ratable over the term, monthly, with proration on partial periods
     At a point in time, on delivery or acceptance, with the trigger
     recorded
     On usage, from metered consumption
     On milestones, where the contract defines them
   
   Each carries its own start and end, which frequently differ within one
   contract. A subscription starting in March and an implementation
   completing in May belong to the same contract and to different schedules
   entirely.
   
   Post the periodic recognition and the deferred balance, with each entry
   linking back to the obligation and the allocation that produced it.

4. 4

   Handle modifications as new allocations

   Getting this wrong is a restatement.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then handle contract modifications properly:
   
     A mid-term upgrade adding a distinct obligation at its standalone price
     is treated as a separate contract
     A modification that is not distinct requires a reallocation across the
     remaining obligations with a cumulative catch-up
     A downgrade or partial termination requires reversing the unrecognised
     portion, not the recognised one
     A renewal is a new contract with a new allocation, not a continuation
   
   Never adjust a schedule directly. Every change produces a new allocation
   linked to the original, with the reason recorded.
   
   This is the part where an error becomes a restatement rather than a
   correction, and it is worth being slow about.

5. 5

   Reconcile bookings through to revenue

   Deferred revenue should be explained, never balanced.

   Copy

   Reconcile every period:
   
     Bookings against contract value entered
     Contract value against total allocated, which must agree exactly
     Allocated against scheduled
     Scheduled against posted revenue
     Opening deferred plus billings minus revenue against closing deferred
   
   Every difference must be explainable, and none may be plugged. A
   balancing entry in revenue recognition is the entry an auditor finds.
   
   Report per period: revenue by obligation type, deferred balance and its
   ageing, contracts with no allocation, allocations with no schedule, and
   modifications processed with their treatment.
   
   Contracts with no allocation is the one to watch. Each is revenue nobody
   is recognising.

6. 6

   Validate, then hand the price table to revenue accounting

   Because standalone prices change and the table is theirs.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run parallel with the existing spreadsheet for two
   periods and reconcile every difference before trusting it.
   
   Then open the same workflow in Tray Build so revenue accounting can
   maintain the standalone price table and the obligation templates in the
   visual canvas.

What it connects to

The contract defines the obligations, the ERP holds the ledger, and the working has to survive both.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides