Watch one contract become a journal entry.

Three passes, not one. The first reads the contract and records what it finds. The second writes the ASC 606 determination from those recorded facts — not from the document. Contracts that trip a flag escalate to a third, more capable pass.

Splitting the reading from the reasoning is deliberate: the step that interprets never sees the raw prose, so it cannot quietly invent a term that was not extracted.

Scanned, image-only PDFs are rejected with a message asking you to OCR and retry — the engine does not guess at pixels.

Not a summary of them — the five the standard actually specifies, in order, each producing something you can read and disagree with.

Step four is the one people assume is automatic. It is not: the proposed allocation is checked against a deterministic allocator running decimal arithmetic, and a divergence past five cents becomes a judgment you have to answer.

Nothing has posted. Nothing has been created in your ledger, because at this point no contract record exists at all — what exists is a proposal: the determination, the judgments behind it, the paragraphs it turned on, and the alternative it weighed and set aside.

It waits there for a person with the authority to approve it. Approve it, change it and certify your version, or reject it with a reason that stays on the record. Only then does a contract exist.

The accounting judgment stays yours. The engine does the arithmetic and keeps the evidence.

Twelve periods, derived from the treatment you approved. The waterfall is recomputed from the contract and its approved template every time you open it — there is no stored number to drift out of agreement with the contract.

The rounding residual lands on the last period, so the schedule ties to the transaction price exactly rather than to within a cent.

At month end the engine drafts the recognition entry from the approved treatment and queues it for review. Approving it does not send it anywhere.

By default the month posts as a single consolidated entry, and someone holding posting rights — re-authenticated — is the one who posts it. Two people, two moments, both on the record.

• Prepared for QuickBooks, with your chart-of-accounts codes resolved onto the lines
• A posting key makes a retry a no-op, so a re-run cannot double-post
• Posted entries are read back daily and any drift is reported, never silently repaired