Bank statement to books: how every row becomes a voucher, or a question

About the product details. They describe the AawazAI app as built today, and screens can change between releases. Every name, GSTIN and amount in the examples is made up. For tax questions, ask your CA.

What you can upload

Net-banking exports come as a spreadsheet: CSV, TSV, Excel or Apple Numbers. A digital PDF has a text layer, which is rebuilt into columns by where each figure sits on the page. A scanned PDF or a photo is copied row by row by a vision model, one call per page, for up to 12 pages. Whatever the source, the result is the same table: date, narration, reference, debit, credit and balance, with the opening and closing balance and the last four digits of the account.

Amounts are kept as exact decimals, and the importer never invents a figure the paper does not print. A spreadsheet is read as data, not by an image model. AI reads, which a scanned page needs, are what credits pay for; the pricing page lists them.

Step one: prove the statement

A bank prints two facts that make every row checkable:

Opening+ creditsless debits= closing

and each row's balance equals the previous balance plus its credit less its debit. A copy that satisfies both, to the paisa, has every amount right. A copy that breaks them has a wrong figure, and the first row where the running balance stops following is where it is.

When a single-digit change in that row closes the chain, for instance an amount read as 1,284.50 for 1,234.50, or a balance misread, the arithmetic has proved the fix, so it is applied and recorded with the printed value kept for undo. A credit that sat in the debit column is handled the same way. At most three such fixes are made automatically; beyond that the copy is not "one misread digit" and you see it.

If the statement still does not add up, nothing is booked from it: books built from wrong rows are wrong in the same place. The screen highlights the row to fix first. This is one of the few places AawazAI refuses rather than warns, because it is arithmetic, not opinion.

Step two: what each row is

Classification runs database first, and stops at the first answer:

1. Already in the books. A voucher on this bank with the row's own key from an earlier import, or the same money, the same way, within three days, paired one to one with reference matched first. It is shown, never booked again.
2. A customer paying. A credit that equals an open bill's balance, or names the bill number or the customer, becomes a receipt against that bill.
3. A supplier paid. The same logic for a debit and an open supplier bill.
4. Narration rules. Interest credited, bank charges and the GST on them, ATM withdrawals, cash deposits, GST challans, EMIs, loan disbursals, transfers between your own accounts. These are the wordings banks print the same way everywhere.
5. Your own past choices. The head you picked for a narration before, learned only from your choices.
6. Otherwise a question. A credit offers Sale, Owner's capital, Loan received or Other income. A debit offers Expense, Purchase or Owner's drawings. Nothing is chosen for you.

Every answer carries a confidence and the reason behind it. Rows at 90% or above can be accepted together in one tap. A row the books and the arithmetic prove (it is this open bill) is applied at once, with undo.

A sample statement

We ran a made-up October file through the app: opening balance ₹12,50,000, five rows, no account number in the file. This is what the review screen proposed.

The proof read: credits ₹4,91,218, debits ₹3,30,236, closing ₹14,10,982, reconciled. In a second run we changed one balance to read 14,26,000 where the running total needed 14,25,000. The app changed that one digit back, recorded the printed figure beside it, and the statement still showed as adding up.

Step three: booking

Only rows with a decision are booked, and each is its own voucher through the same posting engine every other entry uses. A receipt settles the customer's open bill, oldest first if none is named. A supplier payment settles the supplier's. A transfer moves money between your own accounts. Bank charges, interest, GST challan and loan EMI each have their own heads. The row's key (bank, date, direction, amount and a digest of its reference) is stamped on what it books, so a double tap, a retried confirm or a re-upload finds it and books nothing.

Each row runs on its own. A row the books refuse, because the period is locked, the GST month is marked filed, or the bill is already settled, is reported with its reason and every other row stays booked. Rows still waiting for a choice stay on the statement for later.

Bank rows and GST

Two cautions that apply to every package. A GST challan debit is a payment into your cash ledger on the portal, not an expense; it is booked as a GST payment. And money received from a marketplace or payment gateway usually arrives net of their fee and any tax collected at source, so the bank credit is not your taxable sale. Tie such credits to the settlement report, not to the sale. Your CA works from sales and purchase documents, covered in what your CA needs every month.

What stays with you

You choose the head for a line the system cannot place, you accept or undo a suggestion, and you decide what to do with a statement that does not add up (usually: download the full statement again, because a row is missing). The statement is also useful as evidence: upload it on the audit-readiness screen and your CA can tick bank entries against the bank's own record.

Frequently asked questions