Books demo tour · Part 3 of 6
Everything the books need, arriving on its own.
Bank and card feeds stream transactions into the book as they clear - in the United States, where the automatic feed runs today. Everywhere else you upload the statement, and it does the same job: its lines are the bank side, matched against the ledger exactly as feed rows are. Receipts, bills, and statements - emailed or uploaded - land in a document inbox where the OCR engine reads them, scans included, so every document becomes matchable evidence instead of a flat picture.
Illustrative client book: Hudson & Vale CPAs, LLP keeping the books of Harborlight Community Health Center, Inc. - a fictional nonprofit community health center. Fictional firm, client, and data.
Bank feeds
Connected accounts, streaming in
The automatic feed runs on Plaid and Books asks it for United States institutions, so today that is where a bank connects itself. If your organization banks anywhere else, read the next panel before you read this one - the statement path is not a downgrade.
| Account | Feed | New | Last sync |
|---|---|---|---|
| First Harbor Checking - Operating | ● Connected | 27 transactions | 8 minutes ago |
| First Harbor Savings - Reserve | ● Connected | 2 transactions | 8 minutes ago |
| Harbor Business Card ····4417 | ● Connected | 12 transactions | 9 minutes ago |
| Meridian Trust - grant account (no feed) | ↑ Statement uploaded | 64 statement lines | June statement · PDF |
books_bank_sync_feed_connection · the bot can pull a fresh sync before it starts categorizing. The fourth account has no feed - the bank is outside the United States, or Plaid does not reach it - so the statement carries it, and nothing downstream can tell the difference.
No feed
The statement is a path, not a fallback
Outside the United States there is no automatic feed today, and we would rather say that plainly than let you discover it after signing up. What you do instead: upload the statement - a CSV export or the PDF itself - onto the account. With no feed connected, those lines ARE the bank side of the reconciliation. They match against the ledger exactly as feed rows do, so the account ties out rather than merely storing a document.
| What the upload does | Detail |
|---|---|
| Reads CSV or PDF | A PDF goes through the same tiered extractor the document inbox uses - direct text, OCR, Google Document AI, then a vision pass - and the extracted text is cut into the same columns a CSV would give. |
| Says what it read | It reports which physical column it took as date, description and amount, whether it got that from the header or from position, and how it resolved DD/MM against MM/DD - so you can correct it instead of inheriting a confidently wrong workpaper. |
| Never silently drops a row | A line it cannot parse comes back with its physical line number and its raw text. One bad row does not cost you the other two hundred. |
| Derives the closing balance | From the statement's own running balance where the file states one - and honestly reports that it cannot when the file does not. Your typed figure always wins over the derived one. |
| Feeds the same workpaper | Outstanding checks, deposits in transit, bank charges, interest and returned items are named as reconciling items, adjusting entries arrive as drafts you post, and a person signs as preparer and a different person as reviewer. |
The bot does the heavy lifting
- Imports statement lines over MCP too (books_recon_import_statement_lines), so your AI can do the upload leg as well.
- Matches uploaded lines to the ledger with the same matcher that reads feed rows - one answer for both sides, so no sheet can tick a row the workpaper reports as outstanding.
- Tells you which source the closing balance came from - the feed, your upload, or a figure you typed.
You stay in control
- You correct any column the parser read wrong, and you can type the closing balance over anything derived.
- You see every line the parser could not read, with its line number - nothing is quietly dropped.
- The signatures are the same as on any other workpaper: a preparer, and a different person as reviewer.
Document inbox
Receipts become evidence, not attachments
The inbox reads every document with the built-in OCR and Google Document AI engine - vendor, date, amount, and line detail extracted - then suggests the transaction it belongs to. Matched documents live in the evidence vault, attached to the entry they support.
| Document | Extracted | Suggested match | Status |
|---|---|---|---|
| staples-receipt-0614.jpg | Staples · $214.67 · 06/14 | Card ····4417 · 06/14 · $214.67 | Indexed · match proposed |
| ConEd-invoice-june.pdf | Con Edison · $1,893.40 · due 07/05 | New bill → Utilities | Bill proposed |
| OMH-grant-award-FY27.pdf | NYS OMH · $180,000 · award letter | Grant record · restricted | For your review |
The bot does the heavy lifting
- Reads scans and photos with OCR + Google Document AI - no retyping.
- Proposes the match, the bill, or the expense - with the source document attached as evidence.
- Runs the whole invoice and bill lifecycle on your instruction: create, edit (amounts lock the moment a payment is applied - the bill.com rule), send with your say-so, mark paid, undo.
- Routes anything unusual (like a restricted grant award) to your review queue instead of guessing.
You stay in control
- You approve matches and bills before they touch the books.
- Evidence completeness shows on the dashboard - you always know what's unsupported.
- Clients can email or upload documents without ever seeing the ledger.
▶ Watch: feeds streaming and the inbox reading receipts
Screens are illustrative: Hudson & Vale CPAs and Harborlight Community Health Center, Inc. are fictional.