Performance obligations: field notes from messy contracts

Most false confidence in a financial auditing app for revenue recognition checks begins upstream — when the contract packet was never translated into obligations the tool can see.

Teams paste SKU lists into attribute tables and hope the checker invents the commercial story. It will not. The story has to be written first.

Start with promises, not invoices

Read the customer’s enforceable rights before you look at billing schedules. Installation services that look “free” on a quote often fail the distinct-goods test once you ask whether the customer can benefit from the license alone.

In Korea-facing manufacturing deals, we repeatedly see tooling and first-article support bundled into a single line. Separating those promises on paper — even if pricing stays negotiated — prevents the checker from treating the entire amount as product revenue on shipment.

A working sequence

Annotate the master agreement for change-order clauses. List each deliverable that transfers independently. Note which ones are highly interrelated. Only then design attributes: obligation ID, transfer pattern, SSP source, and modification trigger.

When learners in our Audit Studio skip this sequence, Module 3 Lab runs explode with amber flags that look like system failures but are really mapping failures.

What “good enough” looks like

Perfect taxonomy is rare. A maintainable map that finance and sales ops both recognize is enough for the first automated passes. Revisit after each material amendment — not once a year when someone remembers.

Explore the Audit Studio if you want structured practice on this intake work, or return to the journal.