Postings proposed from documents: a person approves

When Achekam proposes journals from supplier invoices, receipts and bank lines, who approves and posts them, and what waits in the Intake Review Queue.

By Achekam · 11 October 2026 · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya

A box of supplier invoices, a folder of till slips and three months of bank statements arrive for a client whose books are behind. Software that reads documents can turn that pile into proposed journals in a fraction of the time it takes to capture them by hand. The question a firm has to be able to answer, for its own quality control and for anyone who later relies on the books, is who decided each entry.

In Achekam the answer is always a person. Journals proposed from documents, bank lines or adjustments are candidates, and only a person can approve and post one. This article explains where candidates come from, what limits apply to reading documents, how bank lines are matched and where the doubtful items wait.

Where candidates come from

Posting candidates come from three places:

• documents, such as supplier invoices and receipts read into their fields;
• bank lines, from imported bank statements;
• adjustments the team proposes.

They are listed under FINANCIAL INTAKE > Posting Candidates. Treat every one as a proposal, and review it with the invoice, slip or bank line it came from open beside it. A candidate that looks reasonable on its own can still be wrong for the client: a personal expense paid from the business account, or a capital item proposed as a repair.

Reading invoices and receipts, and when scans can be read

Achekam can read supplier invoices and receipts into their fields and propose a journal for each. Typed and digitally generated documents are the straightforward case.

Scans and photos are different. Achekam reads them only when an outside OCR service or an image-reading AI key has been set up. Without one, a review item OCR_ENGINE_NOT_CONFIGURED is raised instead of a guessed reading. If your team photographs till slips on a phone, check that one of those is in place before a client's shoebox arrives.

One detail matters for VAT. Where VAT is not printed on a document, the VAT field stays empty. Achekam does not work backwards from a total to invent a VAT amount, which is right: a supplier who is not VAT registered, or an invoice that is not a valid tax invoice, should not produce an input tax claim.

Staff can also upload a receipt, invoice or statement to Document Intelligence for AI to read. Achekam then re-checks totals, VAT and dates and flags any figure not found in its own transcription of the document. Restricted data classes, such as payroll and bank data, are refused there unless allowed for that purpose.

Bank lines and suggested matches

Staff can import bank statements as PDF, CSV, Excel, OFX, QIF, MT940 or CAMT.053 files. Achekam checks that the opening balance plus the movements equals the closing balance, so a missing page shows up immediately. Scanned or photographed statements are read by text-recognition software on Achekam's own server, which is on by default, and checked against the running balance.

For each bank line Achekam may suggest a match, for example to an invoice already captured. A person accepts each suggested bank match. An accepted match is still a candidate until it is approved and posted.

Only a person approves and posts; AI is refused

Approving a candidate and posting it are two steps, and only a person can take either. AI is refused both. This is enforced in the AI engine too: it refuses any task whose type is giving an opinion, reaching a conclusion, approving or signing.

That leaves AI where it is useful, reading documents and suggesting, and keeps the decision with someone accountable for it. In practice:

For volume work, set a rule in the firm about who approves and who posts for each client, and whether one person may do both. A preparer approving their own candidates is a weaker control than a second person reviewing them. ICAEW's article on how to identify and deal with fake invoices lists warning signs a reviewer can look for, such as an invoice that does not match its purchase order or delivery note, and preventive controls such as segregation of duties.

The Intake Review Queue

Not every candidate is ready for approval. Low-confidence fields and possible duplicates wait in the Intake Review Queue for a person. A field Achekam is not sure it read correctly, or an invoice that looks like one already captured, does not go forward on its own.

Duplicates deserve particular care. The same supplier invoice often arrives twice, once as a PDF by e-mail and once as a photo of the paper copy. Resolving the queue item, rather than approving both candidates, is what prevents the expense and the input VAT being claimed twice.

A review routine for posting candidates

1. Clear the Intake Review Queue for the client first.
2. Check scans were read with OCR or AI set up, not skipped.
3. Review candidates with their source documents open.
4. Confirm VAT only where the document shows it.
5. Accept bank matches line by line.
6. Approve and post, ideally with two different people.

Keeping the decision with people

The time saved by reading documents is real; the control comes from people approving what was read. Bring that into your engagement planning so each client's capture work names its approver. Where the client sends a full ledger instead of documents, see turning a general ledger export into a trial balance, and for trial balance files see uploading a client's trial balance: what is read.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.