Bookkeepers lose month-end to the uncategorized transaction chase

The problem

A freelance bookkeeper with a portfolio of small-business clients closes each month with the same residue: bank transactions that cannot be categorized without the client. A card charge to an unfamiliar vendor, a transfer with no memo, a payment that might be personal or might be inventory.

The usual fix is a spreadsheet or a long email listing every open item. Clients skim it, answer half, and forget the rest. The bookkeeper chases, parks the items in a suspense account, and either delays the close or files numbers they are not confident in. The cost is unbilled chasing time and a close that slips.

Ledger tools offer client query features, but they assume the client logs into the accounting app, which many small owners avoid. Receipt-capture apps solve a neighbouring problem. Nothing makes the specific question cheap to answer from a phone in a minute.

Constraints

• Budget: a solo bookkeeper pays per client per month, so running cost must stay low.
• Skills: the bookkeeper is not an engineer and will not maintain rules files or prompts.
• Clients: non-technical, phone-first, unwilling to create another account.
• Data: financial records under data protection and record retention rules, so storage is minimal and scoped per client.
• Trust: the bookkeeper signs off on the books. Nothing posts to the ledger without their approval.
• Integration: data lives in hosted ledgers with rate-limited APIs and per-client authorization.

System design

A read-only connector pulls transactions from the ledger on a schedule. Plain code selects open items: anything in the suspense or uncategorized account, or above a threshold without an attachment. Deterministic rules then clear what history already answers, such as a vendor this client has always categorized the same way.

The remaining items go to the model for one narrow job: rewriting a raw bank line into a plain question the owner can answer, with likely options drawn from the client's own chart of accounts. Code supplies the options; the model only phrases and orders them.

The client receives a scoped, expiring link. Each transaction is a card: tap an option, type a sentence, or attach a photo of the receipt. Reminders run on a fixed deterministic schedule.

Replies come back to the model a second time to map free text to a proposed category and flag anything ambiguous. Every proposal lands in a review queue. The bookkeeper approves in bulk, and only then does an idempotent writer post the change, keyed by transaction ID so a retry never double-posts.

Trade-offs

Nothing auto-posts, so the bookkeeper still spends a few minutes per client on review. That is the point: accountability stays with the person who signs.

Expiring links are weaker than full accounts. Scoping each link to one client's open questions and storing no ledger credentials on the client side keeps the exposure small.

Supporting one ledger first means turning away some users. Broad ledger coverage is a maintenance burden a solo builder should earn, not assume.

What I would build first

I would start with one ledger, read-only, and no write-back at all. A weekly job lists open transactions for a single client, generates the question page, and exports answered items as a CSV the bookkeeper applies by hand.

The only metric that matters in the first two weeks is how many questions clients answer without being chased, compared with the spreadsheet they used before. If that number moves, write-back and the review queue are worth building.

When a workflow stalls on someone else's reply, lower the cost of answering before you automate anything downstream.