01
The problem
The problem
Revenue recognition under ASC 606 usually lives in a spreadsheet that one person owns. Every month they rebuild the schedule, calculate the movement, and key the journal entries in by hand. It works until that person is out, or until the auditor asks how a given number was derived.
02
How it is built
How it is built
- 1Schedule trigger runs the recognition pass each period. A companion intake sub-workflow, triggered when a subscription invoice is issued, has already built the schedule and posted the initial deferred entry.
- 2Data Table block reads the schedule rows that come due this period, so the workflow, and the auditor, can see the full plan per contract.
- 3Loop block iterates each due contract.
- 4Code block computes the amount to move from deferred to recognized, following the same rule every time.
- 5Rillet or NetSuite block posts the journal entry with the contract reference attached.
- 6Slack block reports the period recognition total to the team.
03
Why it holds up in an audit
Why it holds up in an audit
| Question the auditor asks | What the workflow shows |
|---|---|
| How was this schedule derived? | The code rule and the source contract term |
| Who can change it? | The workflow, not a person editing a cell |
| Where did this entry come from? | A posted JE linked to its contract |
| Is it applied consistently? | Same rule, every contract, every period |
Want this workflow built and maintained for your finance stack?
Book a demo