Skip to main content

​
3 · Hand it to the Clerk

What you are doing. Moving a signed document out of the composition lane and into the review lane. One button. The document enters the Clerk’s intake queue as a normal reviewable row, and the document page records the handoff.

​
Submit

duplicate_of and duplicate_of_version ride back on the response because “filed” and “filed as a second version somebody now has to choose between” are different facts on a money path, and a bare success would report them identically. Both are null on an ordinary submit.
The submit is idempotent, through the intake queue’s own partial unique index. A double-submit resolves to the same intake row and is reported as "outcome": "duplicate" rather than as either a second row or a silent no-op.That distinction matters: a silent no-op and a successful submit look identical to a caller, so the caller cannot tell whether a retry worked.

​
What just happened underneath

The handoff is not a status change on the document. It creates a row in a different system - the Clerk’s intake queue - and records the link in both directions. The document page keeps the handoff as part of its permanent record: Submitted, the timestamp, the identity that submitted it, and an open in review link that carries the intake id. That link is one direction of a durable lineage chain. After posting, Transactions resolves the accounting event back to its native source, approved workpaper and intake document when those records exist; unresolved historical evidence remains missing or legacy_unverified rather than being guessed.

​
It arrives in the review inbox

Follow open in review, or go to Books → Review. The new row is drafted by typewriter and ordinarily lands at ready to review with no Clerk extraction flags. That is because the handoff projects the schema payload directly into intake_queue; it does not re-run the Clerk graph, classification, extraction or Teable master resolution. A conflict with another live version in the same document group can instead land as flagged for a human to choose.
Line items are shown as raw JSON in the detail pane. The count underneath - “1 line item extracted” - is the readable version.

​
What you cannot do here, and why

Submitting is not approving. A composed document arrives in the queue as something a human still has to judge, exactly like a PDF someone dropped into chat. It arrives unflagged rather than pre-approved, and those are different. Unflagged here means no Clerk extraction pass produced a doubt, because no such pass ran. It does not mean the amount is right, the supplier is right, or that the document should be in your books at all. That is what gate 1 is for.
Send back will not work on this row. A Typewriter-composed document lands at ready to review, and send-back is only accepted for rows the Clerk actually flagged. The control is present and enabled on a row that can never accept it, and the server refuses the click.There is nothing to send back to: a schema-built document has no agent extraction to redo. If it is wrong, reject the queue row and revise the document in the Typewriter. The full explanation is on Working the review inbox.

​
Next

4 · Gate 1, the intake approval

Read the flags, then decide. Nothing is in the ledger yet.