Artificial intelligence
AI for a professional practice: read the documents received, not the advice
A practice does not lose its time on advice. It loses it opening crooked photographs to find which of the twelve documents is still missing.
An accountancy practice in Sétif, a Monday at month end. The inbox holds forty messages, thirty of them with an attachment: photographs of invoices taken on a counter, statements as PDFs, a payslip scan sent twice, and a file called "document".
Nobody in the practice has started work on a file yet. What has just arrived is not advice, it is document handling, and that is where an artificial intelligence system can give hours back. This article asks how far exactly, and where it has to stop.
The answer rests on a distinction: reading a document and producing an opinion are separated by one operation, summarising. This article covers everything that precedes that operation, and why it has to stay with you. It does not repeat what a practice may write about law or tax, nor the grouped request for documents, which are covered elsewhere.
What actually arrives in the inbox
Take a week’s inventory and note the form of each document received, not its content. You will get a spread everybody in the trade recognises: photographs taken on a phone, PDFs produced by a bank or a portal, scans of varying quality, and a few native, well-named documents.
Those forms are not handled the same way. A bank PDF contains text: it is read without character recognition and extraction from it is reliable. A photograph of an invoice lying crooked on a counter contains an image; everything that comes out of it has been through recognition, with the errors that implies.
The proportion between the two decides half the project, and it varies enormously with the client base. A practice whose clients are already computerised companies receives mostly text; a practice looking after shopkeepers receives mostly photographs, and its work is entirely different.
That is the first figure to establish before listening to any supplier, and it is counted by hand in an hour. A demonstration run on well-formed PDFs predicts nothing about what happens in your Monday-morning inbox.
Reading is not understanding: what a system extracts from a document
On a document a system does something narrow and useful: it pulls named fields out of it. The nature of the document, a date, an amount, a number, an issuer, sometimes a tax identifier. Those fields are verifiable one by one, and that is what makes them acceptable.
What it does not do is understand what the document is for in the file. A capital-asset invoice and an expense invoice have exactly the same shape; what separates them is an accounting decision depending on the activity, the threshold adopted and the director’s intent. A system that settles that produces an entry nobody decided.
The rule that follows is the same as in the neighbouring articles of this file: what is legible on the document may be extracted, what is inferred from context belongs to the professional. A supplier offering "automatic bookkeeping" is selling the second thing under the name of the first.
So ask to see the raw fields, with the value as it was read, beside what the system proposes. If the screen shows only the proposal, you will never be able to tell whether it came from a reading or from a guess.
Completeness is the only question the machine should settle
There is one question, and only one, a system can decide on its own without risk: is this document part of the list expected for this file, and which one is still missing. It is a comparison between what arrived and a list you wrote, and it commits no judgement.
It is also the largest gain, because chasing a missing document is what consumes the most back-and-forth in a practice. A system that answers "you still owe the December statement and the certificate" the same day, instead of somebody discovering it three weeks later, changes the shape of the whole month.
Two conditions make it possible and both are yours. The expected list has to exist per type of file, written once, and it has to be short. And the document received has to be attachable to a file, which assumes your clients write from an address or a number you know.
When those two conditions are missing, no tool replaces them: it will hand you a list of gaps on a file it chose itself, which is worse than nothing.
What is never read automatically
Four categories resist, and it is better to know them before buying. The first is handwriting: a note added by hand on an invoice, a signature, an annotation in the margin. Recognition returns a result, often plausible, and it is wrong often enough not to be usable without rereading.
The second is the stamp and the seal, which sit over the text and make it illegible at exactly the place that matters. The third is the photograph taken against the light or at an angle, where recognition invents digits — and an invented digit on an amount is the worst of defects, because it is plausible and travels the whole chain.
The fourth is subtler: the document in handwritten Arabic, or scanned in poor quality, for which the tools are markedly worse than in French. It is a local fact that appears in no brochure, and it concerns a real share of the administrative documents a practice receives here.
The consequence is not to give up, it is to separate the flows: what is legible goes through extraction, what is not goes into a queue for a person. A system claiming to handle both at the same level will have you reread everything, and you will have gained nothing.
Filing gains more than reading does
Reading a document is fascinating; filing is what gives hours back. Naming a file, attaching it to the right client, the right year and the right heading is a gesture repeated dozens of times a day, and it is exactly what a machine does well when the rules are written down.
Naming is a practice decision worth settling before any tool: client, date, nature, number. A convention that is kept is worth more than a search engine, because it survives a change of software and because it reads without opening anything.
Attaching to a file is where an error costs, and it is handled in section 10. What matters here is that the system must propose a file and a heading, never impose them, and that a document whose attachment is uncertain goes into a queue rather than into a file at random.
A practice installing only that function — naming and attachment proposed, completeness checked — would already have taken the largest share of the benefit described here, without touching the substance.
What the system never tells the client
One sentence is forbidden, and it is the one everybody wants to automate: "your file is complete" in the sense of compliant. The system knows it has received twelve documents out of twelve; it does not know whether the twelfth is the right one, whether the statement covers the right period, or whether the certificate is still valid.
The wording that holds is more modest and perfectly useful: we have received these documents, these are missing, a member of the practice will check. It gives the client what they want — certainty that their sending arrived — without committing the practice on substance.
There is a second prohibition, quieter: the system gives no indication of timing that resembles a commitment. "Your file will be handled within X days" is a promise the practice’s calendar does not always keep, and it will be quoted back on the day it does not.
Those two rules are not legal caution: they are the conditions for the tool to stay useful. An acknowledgement clients stop believing saves no time, it costs time in explanations.
Advice is not a summary
The request always comes, and it is attractive: since the system reads the documents, let it produce a summary of the file for the professional about to handle it. That is where we stop, and the reason is not caution.
Summarising is deciding what to leave out. On a tax or legal file, what is left out is exactly what would have changed the answer: a mention at the foot of a contract, a date that starts a limitation period, a statement line that looks like nothing. The professional reading the summary does not know what disappeared, and works with a confidence nothing justifies.
There is a second, slower and graver effect: the summary becomes the version of the file everybody reads. After a few months nobody opens the documents any more, and the practice has replaced its raw material with an interpretation whose author does not exist.
What is useful instead is an ordered list with no commentary: the documents received with their dates and amounts, what is missing, what is illegible. Ordered facts, which the professional reads in ten seconds and completes themselves.
Professional secrecy does not stop at the portal
A practice’s documents contain personal data within the meaning of law 18-07 of 10 June 2018, amended and completed by law 25-11 of 24 July 2025, and they are additionally covered by a professional secrecy specific to the profession, which has a different source and is not handled the same way.
Two concrete consequences. The first is that automatic extraction takes the document’s content out of the practice as soon as it relies on a service hosted elsewhere — that is a transfer, and what may be sent to a model hosted abroad is looked at before the tool is chosen.
The second is that the processing has to be described and the processor has to commit in writing. The clause most supplier contracts are missing is exactly that one, and a practice is better placed than most to read it.
This paragraph describes the state of a regulation at the date of publication and does not replace a lawyer’s advice — an unusual formula in an article addressed to practices, and worth writing anyway: we are talking about your tooling here, not your trade.
What has to stay on the record
A practice needs to know who saw what and when, and that requirement does not come from computing: it comes from professional responsibility. A tool that reads and files documents therefore has to write a log, and that log has to survive a change of supplier.
Three things at minimum: the date the document arrived and by which channel, the value as read before any correction, and the identity of the person who approved the attachment. The second is the one that gets forgotten, and it is the only one that later distinguishes a reading error from a keying error.
The log has to be exportable in a format you can read without the software that produced it. It is a simple requirement to write into a contract, and it is refused often enough to make a good supplier test.
That record also serves something more everyday: after a few months it tells you which documents are consistently a problem and with which clients. That is the material for a useful conversation with them, and it does not exist without a log.
The error that costs: a document in the wrong file
Of all the possible errors, only one is genuinely serious, and it is not a misread amount. A wrong amount shows up at reconciliation; a document filed under another client’s name does not show up at all, and it does two kinds of damage at once: it is missing where it should be, and it appears where it has no business being.
In a practice, that second half is a confidentiality incident between two clients, quite apart from any technical question. That is why attachment is the only operation in this article that must stay approved by a person, even when the system is confident.
The design that protects is simple: a document whose issuer or reference matches no known file goes nowhere. It waits in a named, visible queue, reread every day. A queue is a daily nuisance; a wrong filing is an error discovered at an inspection.
The setting to ask for is therefore the opposite of the one you will be offered: prefer a system that hesitates often at first. The hesitation rate falls within weeks as the matches settle; a system confident from day one is confident about matches it invented.
The check: thirty documents, four columns
Take thirty documents received last week and fill in four columns: the form of the document — text, scan, photograph — the language, whether it could be attached to a file without hesitation, and how long it took somebody to file it.
Three readings come out of it. The share of photographs tells you whether extraction will be reliable or whether you are mostly buying rereading. The share of documents not attachable without hesitation tells you whether your naming convention and your expected lists really exist. And the filing time multiplied by your monthly volume gives you the theoretical maximum gain — the ceiling of what you can hope for, before a tool is even discussed.
That ceiling is often lower than expected, and it is useful to know before signing. Many practices discover their time goes not into filing but into chasing: the subject then becomes the completeness of section 3, not reading.
The same sheet serves as a specification. It turns a conversation about artificial intelligence into a conversation about thirty real documents, which is the only way to compare two proposals.
What we do, and what we refuse
We connect document intake to your existing channels, write the expected lists per type of file and the naming convention with you, propose attachment without ever imposing it, and deliver the exportable log from section 9. The queue of uncertain documents is part of the delivery, not of the options.
We refuse to produce a file summary, for the reasons in section 7, and we refuse to write to a client that a file is complete or compliant. We also refuse to propose an accounting allocation: that is a decision belonging to whoever signs.
We promise no percentage of time saved. We have no before-and-after measurement on Algerian practices, and the only honest ceiling is the one your own sheet of thirty documents produces — it belongs to you and it is more useful than ours.
What you can do without us is considerable and free: write the list of documents expected per type of file, and settle a naming convention. Those two documents fit on one page, they do half the work described here, and the grouped request at the start of a season benefits from them immediately.
Frequently asked questions
Does this replace an assistant?
No. What is absorbed is the handling: opening, naming, attaching, noting what is missing. File work — characterising, deciding, committing the practice’s signature — is untouched, and that is what fills an experienced assistant’s day.
Our clients send everything by messaging app. Is that a problem?
It is the commonest case and it is workable, on one condition: the number has to be attached to a known file. A sending from an unknown number goes into the queue, which is the correct behaviour — and it is also a good reason to keep your contacts’ numbers current.
Are Arabic documents handled as well?
Less well, and that has to be planned for. Native text reads correctly; a medium-quality scan and handwriting are markedly harder than in French. The practical consequence is to route those documents to human rereading rather than mixing them into the automatic flow.
Can it be used without changing our trade software?
Yes, and that is the order we advise. Intake, completeness and filing sit upstream of your software; they hand it named and attached files. Changing trade software is a separate project, and doing both at once makes each illegible.
What becomes of the log if we change supplier?
It has to leave with you, in a format readable without the tool. It is a clause to write into the contract before go-live, and a supplier refusing it tells you more than a demonstration would.
What is the first indicator to watch after go-live?
The share of documents in the queue, week by week. If it falls steadily, the system is learning your matches. If it stays flat or rises, something changed with your clients or in your lists, and that is the signal to reread the rules rather than endure them.
Where we come in
The filing-time column, multiplied by your volume, gives the ceiling of what a tool can give back — usually lower than what you will be promised.
- We write the expected list per type of file with you, then the naming convention that follows from it.
- Any document whose attachment hesitates goes into a named, visible queue, never into a file picked at random.
- The log of readings and approvals is delivered exportable, readable without the tool that wrote it.
We will draft neither a file summary nor an accounting allocation: those are interpretations, and an interpretation with no author has no place in a practice.
Read next
Law and accountancy: your client does not buy advice, they buy a deadline met
They can judge neither your analysis nor your advocacy. They can judge a delay, a reply, and a document list that was right first time.The year as a calendar: turning a repeated deadline into batch work
A deadline that comes round every year is not a surprise. A practice that treats it as one endures it twelve times.The processing register, filled in on a real case
A twelve-person firm loses a tender on a document it had never heard named. Here are the six columns, filled in on a real assistant.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.