Features
tvmmm is built first for bookkeepers and accountants who handle many clients. It turns a receipt into a structured, reviewable record β then into that client's ledger entry, and only that client's. This page describes the pipeline as designed. The working part you can test today is the plain-text demo, and signed-in accounts can also test image OCR and a QuickBooks Sandbox push; inbox, mobile and production ledger connections are trial-onboarding features, not demo features.
Receipt arrives as text
Vendor, date, totals, tax ID
Unsure fields wait for a person
Clean record to the ledger
One intake per client
A dedicated address, mobile upload or shared folder per client β instead of text, email, drive and paper all landing in different places for different clients.
Extraction with confidence
Vendor, date, tax ID, line items and totals, each with its own confidence score. A low score never posts silently.
Review queue, not a black box
Missing fields, mismatched totals and unrecognised tax IDs route to a human review queue, with the reason shown next to the field.
Validation before posting
Line-item sums are checked against the stated total, dates are parsed (not guessed), and tax-ID formats are checked before anything moves toward a ledger.
Approval rules
Confident documents flow through on your approval rules; uncertain ones wait for a person. The rule, not the model, decides what posts.
Sync to your ledger
Clean records post with tax codes and cost centres already mapped, so the ledger entry matches the document β not a retyped approximation.
Supplier rules, per client
Set a rule once for a recurring vendor β category, tax treatment, payment method β and every later document from that vendor for that client is coded the same way. Rules are per client, so one client's Amazon habit never leaks into another client's books. The demo does not yet run supplier rules; they are configured during trial onboarding, after the client's first intake route is agreed.
Match to the bank feed, or create β but not both at random
Per client, decide whether incoming documents create new transactions or match existing bank-feed entries, and apply that rule consistently. That single decision removes the most common source of duplicates in multi-client bookkeeping.
What you can verify right now
Run the live demo: four samples, including a cafΓ© receipt that deliberately fails two checks. Paste your own plain-text receipt and watch the same checks run. If a field is missing, the demo says so β it does not invent a value.