The inbox learns from your corrections
Five phases: an honest pending state, organization-informed classification, GL accounts pre-filled per line, a correction ledger that turns repeated fixes into rules you approve, and the first vertical parser.
In June we wrote about the brain, the resolver that decides what a document is and who it belongs to. This is the next step: the inbox proposes the coding as well as the identity, and every correction you make is kept as organization knowledge.
It shipped in five phases.
Phase 0: stop inventing
A document being classified used to display a provisional guess as though it were a fact. A receipt that hadn’t been read yet would show up already labelled a rent check. Pending means pending now. Nothing appears until it’s known.
Phase 1: classification that knows your organization
Classification runs over the OCR text with your organization’s context supplied: your vendors, your accounts, your properties, your naming. The same invoice PDF classifies differently for a property manager than for a general contractor, and it should.
Phase 2: GL accounts pre-filled, and a knowledge rail
Parsed line items arrive with a proposed GL account per line, drawn from what you’ve coded this vendor to before. Beside the document is a read-only rail listing the rules and past decisions the proposal came from. Every change you make is written to a correction ledger.
Phase 3: corrections become rules
The correction ledger feeds the Review Rail. Correct the same merchant three times and the rail offers to make it a rule, prefilled from your corrections. Accept it and the next document from that merchant arrives already coded. Vendor-anchored rules also appear on the vendor’s own page, so a vendor’s coding rules are editable where you’d look for them, and you can add a rule or a parser quirk from either the vendor page or the inbox item that prompted it.
The bank feed works the same way. Categorize a feed item and Zeno offers to make it a rule inline, instead of sending you elsewhere to describe what you just did.
Phase 4: the first vertical parser
NYC property tax bills have a parcel identifier and a layout nothing else shares. They get a dedicated signal and their own prompt. That’s the pattern for any document type common enough to be worth specializing: detect it, then read it with a parser that knows the form.
Documents move to R2
Attachments store in R2 by default rather than through the on-premises file agent. Leases, buyer files, payment scans, and eviction and note attachments all moved, and reads no longer depend on the agent being up. The file agent is still available for organizations that need documents on their own hardware, as a per-organization flag.
Live for every organization. The corrections are the training data, so correct it loudly: [email protected].