Parsing

Parsing covers everything that turns a document into transactions, and it works two different ways. AI Parsing reads a receipt, an invoice or a payment confirmation and fills the entry form in for you. Statement Import reads a bank statement you exported yourself, and it uses no AI at all. They are grouped because that is how you meet them in the product. They are explained separately here because they are metered separately, and treating them as one thing is the quickest way to be surprised by a limit.

​

AI Parsing

Parsing turns a financial document into a pre-filled entry form. It never saves anything on its own: you see every extracted field, you change what is wrong, and you confirm. An entry created from a parse you approved is recorded as one you made, because the thing that matters is your confirmation and not the extraction. All three doors draw on one allowance. Upload, connected mail and Statement Import share a single daily counter, counted in entries returned for approval. A document that comes back with four entries draws four from it, and a 40-row statement draws 40. A Basic user with 20 entries left has 20 left whatever the source.

​

What AI Parsing reads

Two groups of formats, and the difference is in how each is handled rather than in what you may send. Up to 10MB per file. A converted file has a second ceiling on the amount of text it produces, and a file that exceeds it is refused with a clear error rather than quietly shortened. A truncated spreadsheet loses entries you believe were captured, which is worse than a refusal you can act on.

​

What comes back, and what you confirm

Seven fields: type, amount, currency, date, the vendor or source name, a suggested group, and whether it looks recurring. Each carries a confidence value between 0 and 1, and anything below 0.6 is flagged on the confirm form so the uncertain values are the ones you look at first. Every value is a suggestion. Change any of them before you save, and add groups, a description or a receipt exactly as you would on a manual entry.

​

Your daily allowance

The entry allowance is what the day’s reading produces: one receipt that returns one entry draws one, and a statement that returns 40 draws 40. It resets at midnight UTC, and it is one counter across all three doors. The document limit is a separate guard on how many documents are read in a day. It exists to bound what the reader costs to run, and it is not a plan lever: on both plans the entry allowance is what a normal day meets first.

​

What happens to your document

The file is held only for as long as the parse needs it and is deleted the moment you approve or dismiss. Before any of its text reaches the reader it is stripped of personal information, so the figures are read without your name, your email address or an account number travelling alongside them. Nothing you upload is used to train a model.

​

Statement Import

Statement Import reads a bank statement you exported yourself, in OFX, QFX or CSV, and turns it into entries you select, categorize and confirm. No bank connection is involved and there is no facility to create one. You export the file from your bank, and myClerkBook reads the file you chose to give it. One import per calendar month, per book. That single rule produces both plan limits, because what differs between the plans is how many books you hold. Premium allowances are not pooled. An unused allowance on one book cannot be spent on another. The monthly import allowance is spent when you commit, not when you upload. Opening the wrong file, reviewing it and dismissing it costs nothing of your one import a month. The rows it returned are counted against the daily entry allowance as they were returned, and the screen states what you have left of both before you start selecting. A file carries at most 1,000 rows, on both plans. That is a guard against a pathological file rather than a plan lever. Basic’s cap of 100 transactions a month still applies to what you commit, so a Basic book with 40 transactions left this month can commit 40 rows, and the screen says so before you begin rather than after. Duplicates are the feature, not a refinement of it. Re-importing an overlapping date range is normal use.

• OFX and QFX carry your bank’s own identifier for each transaction, so an exact re-import creates nothing.
• CSV carries no such identifier, so its rows are matched against what is already in the book on date, amount and description.
• Every suspected duplicate arrives unticked, with the row it collided with shown. Nothing is dropped quietly. In a financial record, silent deduplication and data loss look identical from the outside.

Your statement is never stored. A bank statement is the most sensitive document myClerkBook will ever handle: an account holder, an account number, a balance and every party you transacted with, most of which the product has no use for. So the file is read while your request is being served and discarded when it ends. It is never written to storage, never sent to any model, and no third party sees it. What survives is a short record that an import happened, holding the file name, a fingerprint, the period covered and three row counts.

​

Related features