A Spanish founder replaces Holded with Odoo 19 Community, his own MCP server and Claude Code, and closes Q3 in it

In two sentences

A Spanish founder stopped using Holded for his company’s books at the end of September 2026 and replaced it with a self-hosted Odoo 19 Community that he operates by talking to Claude Code, through an MCP server of his own with more than forty tools; he says he has already closed the third quarter in it and handed it to his tax adviser. It is a first-hand account in a seven-post thread on X, with an honest list of what went wrong and what he refuses to delegate, but no measured savings, so read it as a well-described pattern rather than proof.

Who does it and why it is interesting

The author is Juanca Hurtado (Juan Carlos Hurtado), who directs Ciade, an AI agency in Spain that builds automations and agents for small companies, including accounting firms, and sells a Claude Code course and ebook. That matters: he has an interest in Claude Code looking good. The thread, published on 9 October 2026, is about his own company, which he does not name, and it reads like a field report rather than an advert: it describes an error, the controls added after it and the things he keeps for himself.

Three things make it worth a closer look:

• It is the real Spanish small-company set-up. A founder who issues invoices, collects expense invoices from portals and email, reconciles the bank and hands everything to an outside asesoría (tax adviser) that files the returns. Thousands of Spanish companies work exactly like this, most of them on Holded, a3, Sage or a spreadsheet.
• He did not reinvent the ledger. “I haven’t reinvented the accounting”, he writes. Odoo Community does the double entry; the AI layer sits on top.
• The hard part was never invoicing. His point is that issuing invoices was never what took his time. The quarter close was: gathering the expense invoices from every portal and inbox, matching them to the bank and leaving everything ready for the adviser.

The stack, piece by piece

What the thread lists, in his order:

1. Odoo 19 Community and PostgreSQL in Docker. The open-source edition, self-hosted.
2. A panel of his own in Next.js 16, React 19, Tailwind 4 and shadcn.
3. An MCP server in Python with more than forty tools, grouped by what they do: register, reconcile, issue, ask.
4. Claude Code, to build it and to use it.
5. Cloudflare Tunnel and Cloudflare Access to reach it from outside, and Google Drive as the archive of PDFs.

Day to day it is used by talking. He passes PDFs and says “register them”, “issue the one for this client” or “which bank charges still have no invoice”. For invoices that were missing, a browser agent went portal by portal; it does not type passwords, does not pay and does not send emails, and when a login is needed it tells him.

Two pieces of context from Odoo’s own documentation help to read this:

• Invoicing versus Accounting. Odoo describes Invoicing as the app for invoices, bills and payments, and Accounting as the full solution that adds standard financial reports, bank reconciliation, budgets and assets. The full Accounting app belongs to Odoo Enterprise, which is why Community installations usually add modules from the Odoo Community Association (OCA); account_reconcile_oca, for example, adds bank-statement reconciliation, is licensed AGPL-3 and is available for 19.0. The thread does not say which modules he uses, or whether his MCP tools cover that gap themselves.
• The new JSON-2 API. Odoo 19 introduced an external JSON-2 API authenticated with API keys that expire (three months at most), recommends dedicated bot users with minimum rights for integrations, and runs each call in its own transaction, so related operations should go through a single method. The old XML-RPC and JSON-RPC endpoints are scheduled for removal in Odoo 22. On Odoo’s hosted plans, external API access requires the Custom plan; that restriction is about Odoo’s hosting, and this set-up is self-hosted.

What went wrong, and the controls he added

“It makes mistakes, of course”, he writes. The one he describes: automatic matching paired two payments of the same amount with the wrong invoice. Every bookkeeper has seen it; amount-only matching cannot tell two identical amounts apart.

His response is structural, not a better prompt:

• Nothing goes in unaudited. A second agent, one that writes no code and only checks, reviews the work before it is accepted.
• Two strikes and it stops. If the auditor sends the work back twice, the system stops and asks him.
• A full manual pass before delivery. Before handing the quarter to the adviser, they went through the 189 bank lines one by one.

And there are three things he does not let the system decide: the date an invoice is issued with, what the adviser is told, and unlocking a journal to correct something. All three are sensible. The invoice date decides the VAT period. What the adviser is told is the company’s tax position. And unlocking a closed period is exactly the control that protects what has already been filed; in Odoo, lock dates prevent posting or changing entries on or before the date, and exceptions are logged in the company’s chatter.

The second testimony: same pattern, different country

A month earlier, on 8 September 2026, Alexander Peiniger, co-founder of the SaaS companies SaaSFlow and Walletguide, described a very similar set-up on X in reply to another user who complained that “everyone is hacking their own thing”:

• Odoo is the in-house accounting system and all bookkeeping, including the Stripe sync, happens directly in it.
• Claude Code does the actual bookkeeping in Odoo via the API; in 99% of cases, he says, they do not touch the Odoo interface.
• At year end the accountant takes an export from Odoo, imports it into DATEV (the software German tax advisers use), checks it and books the year-end corrections, which they import back into Odoo so that Odoo always matches the annual report.
• He says it gives them nearly real-time reports that match the bookkeeping “with 99% accuracy”, that collecting receipts is still a problem, and that it needs an accountant who is open to it.

In a separate post the same day he says that, while gathering everything for the 2025 annual report, he connected the Odoo API to his agent platform and it found mistakes the accountants had not caught “and corrected it in place”. That last part deserves caution: correcting a prior period in place is precisely what the Spanish founder keeps for himself.

Two independent founders, two countries, the same architecture: standard Odoo as the ledger, an agent that works through the API, and the outside accountant as the final reviewer. Neither gives measured savings.

Step by step to replicate it

This is our reading of both accounts turned into steps. Adapt it to your country and agree it with your adviser before the first close.

1. Decide what changes and what does not. The adviser keeps filing taxes; you hand over books and documents. Ask them which export they want (ledger, VAT books, invoices in PDF) before you migrate.
2. Install Odoo 19 Community with your localisation. For Spain, the Spanish chart of accounts and taxes. Check which reports and reconciliation features you need and whether OCA modules provide them.
3. Migrate a clean opening. Open the year (or the quarter) from balances your adviser has confirmed, not from a raw export of the old system.
4. Create a bot user. A dedicated Odoo user with only the rights the tools need, an API key with a short expiry and a rotation date in your calendar.
5. Write narrow MCP tools, not a generic “run any method” tool. For example (the names are ours): register_vendor_bill (always as draft), list_unmatched_bank_lines, propose_match (returns candidates, does not reconcile), issue_invoice (needs an explicit date from you), ask_ledger (read-only). Narrow tools are easier to audit than a model with full API access.
6. Match on more than the amount. Amount plus date window plus counterparty plus reference; when two candidates are equal, the tool must refuse and ask.
7. Add an independent checker. A second agent, or plain code, that verifies every change against fixed rules: balanced entries, VAT rate consistent with the base, supplier tax ID present, no posting inside a locked period, no duplicate invoice numbers.
8. Stop on repeated rejection. If the checker rejects the same item twice, the system escalates to you instead of trying a third time.
9. Keep the browser agent on a short leash. It may look for invoices; it may not type passwords, pay or send anything. You do the logins.
10. Lock each closed period and keep any exception for yourself, with a reason.
11. Review every bank line before delivery. The founder did 189. It is boring, and it is the control that catches the same-amount mismatch.
12. Hand over and reconcile back. Send the adviser the agreed pack, and import their adjustments back so your ledger matches what was filed.

A concrete example (illustrative)

Imagine two bank charges of €121.00 each in the same week, one to a hosting provider and one to a design tool, and two open vendor bills of €121.00 (€100 plus 21% VAT). An amount-only match has a 50% chance of crossing them, and both bills will still look paid. With the rule in step 6, the tool sees two equal candidates, refuses to choose and returns both with their counterparties and dates; the founder, or the checker comparing the bank narrative with the supplier name, links each charge to the right bill. The amounts and suppliers are invented; the error is the one the founder reports.

Stated results

Everything here comes from the founder’s own thread:

• The third quarter of 2026 has been closed in the new system, “with its invoices, its banks and the hand-over to the adviser”.
• 189 bank lines were reviewed one by one before delivery.
• Closing the quarter “is no longer so complicated”, but it is “not install and done” and the system “still lacks things”.

There are no hours saved, no costs and no error rate, and the company and the adviser have not confirmed anything publicly. The second founder’s “99% accuracy” is also his own description, without method.

Limitations and risks

• One-person evidence from someone who sells training. The author directs an AI agency with a Claude Code course. The thread is candid, but it is not independent.
• You become your own software vendor. With a commercial product such as Holded, the vendor maintains the software and adapts it to Spanish tax rules; a home-built layer on Odoo Community makes that your job. Spain’s mandatory B2B e-invoicing now has dates set from 6 October 2026: 12 months for businesses with turnover above €8 million and 24 months for everyone else. On 5 October 2026 the Ministry of Finance announced it plans to postpone the pending VERI*FACTU obligations to October 2028 to align them. Ask your adviser what a self-built invoicing system needs before those dates. In a reply, the founder says he expects VERI*FACTU to be easy to implement; that is his view.
• Community is not Enterprise. Bank reconciliation, financial reports and some localisation features depend on modules you choose and maintain.
• The model can write to your ledger. Draft by default, narrow tools, a bot user with minimum rights and locked periods are what keep a wrong call from becoming a filed return.
• Remote access is part of the risk. A ledger reachable from outside needs real access control; he uses Cloudflare Access, and the principle applies whatever you choose.
• Receipts are still the bottleneck. Both founders say collecting the documents is the part that remains hardest.

Common mistakes

• Starting with the invoice generator. Invoicing was never his time sink; the close was. Automate collection, matching and the hand-over pack first.
• One “god” tool with full API access. If the model can call any method, the checker has to understand everything. Narrow tools make the checks simple.
• Letting the agent fix closed periods. Unlocking a journal is a human decision with a reason, every time.
• Surprising the adviser. Agree the format and the timing first; the German founder notes it needs an accountant who is open to it.
• Skipping the final pass because the checker said yes. The auditor agent caught some things; the line-by-line review is what he did anyway.

Conclusions

This is not an AI that does the accounting. It is a founder who kept a standard ledger, put a layer of narrow tools on top, let Claude Code do the clerical work, added a second agent to check it and kept dates, closed periods and the conversation with the adviser for himself. A second founder in another country describes the same shape. Neither offers numbers, and one of them sells training, so the value here is the design, not the results: if you run a small company in Spain and your quarter close is a week of chasing PDFs, the pattern is worth trying on a copy of your books, with your adviser told in advance and every bank line still checked by a person.