Skip to main content

​
Known rough edges

Everything in these guides works. These are the things that will look odd on day one. All of them are cosmetic or operational rather than dangerous. None of them can put a wrong number in your books, because none of them is on a write path. Document-originated postings reach the single writer behind two human gates; other sources reach it through their canonical domain controls; every path then validates 18 GL invariants before writing.
Publishing a list like this on a product’s own documentation site is unusual. It is here because every item has a stated workaround, and because a reader finds these out in the first hour anyway. Finding them out from the docs is better than finding them out from the product.

​
1 · The Typewriter’s CLERK column understates progress

That column shows what happened at the moment of submission, not where the row got to afterwards. So a document that is already posted and a document the Clerk rejected can both read In review. What to do. Treat the Typewriter’s CLERK column as “was it handed over?” and use Books → Review as the truth about status. It fails safe: it under-reports progress, never over-reports it. A column that said posted when nothing had posted would be dangerous; one that says In review when something has posted is merely unhelpful.

​
2 · Typewriter chat composition - fixed

The Typewriter chat lane is propose-only, so it writes nothing. It now retries an empty extraction within a fixed bound, refuses recursively empty drafts, clears stale errors and reports an explicit failure if it still cannot classify or extract usable fields. Open any proposal in the builder to review its schema fields, save it, collect approval and hand it to the Clerk.
The Typewriter agent introduction in the chat surface

The Typewriter in chat. It proposes a draft; the builder remains the review and save authority.

All five served graphs, including Typewriter, are present in the structural evaluation inventory.

​
3 · Designated approver coverage

Because maker is not checker, a person cannot approve a document they composed. So if a document type has only one designated approver, that person cannot walk a document of that type end to end alone, and neither can anyone else if that approver composed it. What to do. Make sure at least two designated approvers exist for every document type you use in volume. The same change spreads the multi-step approval documents, such as a payment request with four approval steps, across different people instead of collapsing four eyes into one pair.
This is a configuration property, not a defect. The rule is doing exactly what it should; the deployment just needs enough people configured for the rule to have somewhere to land.

​
4 · The posting gate does not grey itself out for makers

The rule is printed under the buttons and names you if you are one of the makers, but the Approve posting button still looks clickable. The server refuses it with a 409, so nothing can go wrong. You just get an error instead of a disabled control. What to do. Read the line under the buttons before clicking.
Note also that the confirmation box stays open behind the error. Retrying will fail the same way. Hand the row to a colleague instead.
There is a defensible reading of this as correct behaviour rather than a defect. A disabled button is a UI convention, and a UI convention is not a control. The server being the control is the property that matters; the greyed button would only be a courtesy. The courtesy is still worth adding.

​
5 · Journal-to-source lineage - fixed

The redundant Journal entries tab is retired. Transactions now resolves each event to a native source, intake record, reversal or approved workpaper and nests its complete immutable entry sets. An unresolved source is now labelled missing or legacy_unverified rather than shown as an ordinary empty panel. Open Books → Ledger, select the event, then follow its exact source/workpaper, journal-entry and reversal references.

​
6 · Chat-borne Files inventory - fixed

Files now retains the same server-owned upload identity for direct and chat-borne uploads. Timeline reports newest-first storage history, Folders keeps unfiled evidence at the root, and the governed Drive reconciliation view remains read-only. An unavailable read is no longer presented as an empty inventory.

​
7 · Currency symbols on Transactions and Matching - fixed

The transactions header and amount column were hard-coded to USD, and the trial balance on what is now Matching printed dong amounts with a $ sign - about 25,000× off at face value. Both now read the base currency the endpoint itself returns, and render BASE rather than a dollar sign when the currency cannot be read.
Money is labelled with the currency it is actually in, or not printed. That is why the Payments page shows no figure yet: its payload carries both a converted and a native amount, and choosing which to show is a data decision rather than a formatting one. A blank is honest; a number wearing the wrong symbol is not.

​
8 · Review-page defects that are now fixed

Four things behaved badly on Books → Review and no longer do. They are recorded here because a reader who learned the old behaviour should know it changed.

​
Also worth knowing

Commissioning data is still in the books. A small amount of end-to-end test data lives in the system from commissioning: documents prefixed TW-, bills named E2E-BILL-…, and one deliberately tiny entry left in place as proof the loop works.Ledger entries are immutable, so removing any of it means posting reversing entries. That is a decision for you, not a cleanup task, and it is exactly the trade immutability makes.