How I Would Build a Bookkeeping System That Hides the Ledger

Direct Answer

A bookkeeping coordination system is a layer that turns incoming commercial documents into accepted myDATA transmissions and a file an accountant can sign. A PDF in an inbox, a supplier invoice, a bank line, becomes a classified record or a named gap — not a chat that “does the books.” This is a designed system, not a deployed build.

Key Takeaways

• The customer problem is not accounting theory. It is that the documents still travel through email before they become books.
• myDATA already publishes a REST API. Connecting to AADE is not the product. The product is matching.
• Law 4308/2014 keeps management responsible for the accounting system. A third-party tool does not take that off them.

What problem does this system actually own?

A Greek SMB already issues and receives invoices. Someone still photographs a paper receipt, forwards a PDF, or leaves a supplier statement in an inbox until Friday. The accountant opens the file, decides what it is, types it into software, and later learns that myDATA rejected the transmission or that the counterparty’s document does not match.

Today the path usually runs like this:

1. Documents arrive as email attachments, WhatsApp images, or a folder on a desktop.
2. Someone forwards the pile to the accountant, often incomplete.
3. The accountant classifies each line: income, expense, VAT treatment, counterparty.
4. Software transmits what it can through an ERP, a provider, timologio, or a form.
5. Rejections and mismatches come back as another email.

None of that is the hard part of accounting. It is information moving between a business, a supplier, AADE, and an accountant who each hold one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with one accountant and one client and walk a single month end to end.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on a chatbot that posts into a ledger.

How the system would run

Take one invoice. A supplier sends invoice.pdf. The system reads it into fields a person can check: supplier name, AFM, date, net €820, VAT €196.80 at the standard 24% rate. It matches that supplier against the file the accountant already keeps, and proposes a classification from the published designation tables — not a chart of accounts I invented. The accountant accepts or changes it. Then the existing channel transmits.

If myDATA rejects the payload, the reason does not stay in a log. The system names the gap. If RequestDocs later shows the supplier transmitted a different net, it asks a person: the amounts do not match — request a correction from the supplier, or leave it for the accountant? A human chooses. Then, and only then, a retry.

Structured intake

A short surface collects what makes a document classifiable: file, counterparty, date, net and VAT, payment method. The model’s job is to read the document into those fields and to name what is still missing. Nobody is asked to pick a myDATA invoice type they do not understand on day one.

Classification

The system proposes a treatment with its reasoning and its confidence. AADE’s current technical specs include an upgraded SendExpensesClassification method and designation combinations as published tables, not as a guess. I would use those published combinations as the constraint, not invent a chart of accounts the tax office does not recognise.

Transmission

Accepted records go out through the channel the business already has: ERP REST API, a licensed e-invoicing provider, or timologio. I would not stand up a second set of credentials “because the agent needs its own login.” Registration for the REST API is already a Taxisnet-gated process on the myDATA platform.

Rejection and counterparty handling

The interesting loop is the one after SendInvoices. The specs describe RequestDocs / RequestTransmittedDocs returning deviation and rejection information from the counterparty. That is a product surface: show the mismatch, say what is missing, and wait for a person. A retry that blindly resends the same payload is how you get a confident error twice.

Accountant review

The period closes when a named accountant accepts the file. The system drafts. It does not become the books.

What stays under human control?

Law 4308/2014 is explicit. Management is responsible for a reliable accounting system and for the financial statements. Using a third party — software or an external accountant — does not relieve them. The statements are approved by the administrative organ and signed by an authorised member and by the responsible accountant.

So the system does not:

• choose a tax treatment the accountant has not accepted
• transmit a record marked as blocked
• sign a period
• invent a VAT position because the model is confident

Self-learning here means usage signals, accountant corrections, and evaluation of classification against what myDATA actually accepted, reviewed by a person. It does not mean the system quietly changing what it declares.

How I would measure the path

Baselines only, before anything is built:

• Share of incoming documents that have AFM, date, and amounts readable on first pass
• Share of transmissions rejected, by reason
• Hours from document arrival to accepted entry
• Share of counterparties where RequestDocs shows a deviation the client had not seen

No conversion or hours-saved claim until those numbers exist.

When this is the wrong build

• The books already live in one ERP that transmits cleanly. Then you are decorating a working pipe.
• The volume is a handful of invoices a year. There is no coordination layer to absorb.
• The documents do not arrive digitally. If the input is a shoebox, the system is a scanner with extra steps.
• Nobody internally can review classifications. Without that reviewer there is no supervised loop, only exposure.
• The accountant’s edge is judgment on edge cases, not retyping. Then you are building software against the part of the work that is not for sale.

How this connects to the engagement

This case is the same shape as the freight quote-to-booking model: a customer who already understands the outcome is forced to learn the industry’s paperwork. The difference is the supply side. Carriers often refuse to connect. AADE already published the interface. The bottleneck moves to matching and to the person who is allowed to sign, which is closer to CE marking.

The system I have actually built is the AI sales follow-up loop inside a CRM. The refusal pattern I would reuse on transmissions is closer to the research loop that knows when not to run.

If this coordination layer already exists in your company as a Friday folder and one accountant’s memory, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

The build starts with the accountant, not the API

The abstraction is one line: a document arrives, the books stay consistent with what AADE already has. The output is an accepted transmission and a period an accountant signed. Between those sits a boring coordination layer that moves information between a business, a supplier, myDATA, and a person who carries the liability. This is a model. It stays a model until an accountant who closes real months describes where the matching actually breaks.