A Spanish family firm runs its own ERP with Claude Code agents: the money controls that made it work

In two sentences

The owner of a small Spanish family business that services car-wash equipment, who says nobody in the company programs, spent two years replacing a commercial package with his own ERP and a team of Claude Code agents that handle the mailbox, work reports, supplier invoices, bank reconciliation and chained invoices sent to the tax agency. What makes the account useful for finance teams is not the ambition but the controls he describes: nothing that moves money happens without a click on his phone, agents must read written procedures before they write, and the money logic is covered by tests that, in public and within a day, found and fixed two real bugs.

Who does it and why it is interesting

Jorge Garzón describes himself as the second-generation owner of a small family company in Spain that repairs and maintains car-wash equipment (gantries, tunnels and jet-wash bays) for two of the big manufacturers and for its own customers. There are “a handful of field technicians, one office” and him. On 9 October 2026 he published a post on DEV Community, in English and Spanish, and in the next day’s comments reported test results and fixes. The company and the replaced software are not named and the account was created that day, so we treat this as a first-hand testimony we cannot verify. He says the text was written with help from the same assistant and reviewed and edited by him.

Why it matters for this directory:

• It is the small-business end of agentic finance. An owner without a technical team has put invoicing, VAT and bank reconciliation in a system he built with an agent, and he answers for it.
• The lessons are about controls, not models. Almost everything he changed has to do with separating proposal from execution, written rules, test copies and tests of the money logic.
• It touches Spanish tax rules. Invoices are “signed and chained” and, according to the comments, registered with the tax service, which raises questions we cover below.

What he built, piece by piece

According to the post, the company now runs:

1. Its own ERP in production, replacing the commercial package it used for years. It covers service calls, work reports filled in on the technicians’ phones, quotes, purchase orders, supplier invoices, bank reconciliation, payroll inputs and, “since this month” (October 2026), the electronic invoicing regime that is becoming mandatory in Spain. Once an invoice is issued, the database itself refuses any change.
2. A set of agents built on Claude Code and an MCP server. They read the mailbox, turn manufacturers’ emails into service calls, draft replies, reconcile what the manufacturer approved against the company’s work reports, prepare supplier orders and prepare emails, which they never send.
3. A technical library that technicians query from their phones (outside the scope of this article).
4. Human approval by Telegram. Anything with consequences (creating a document, changing a price, sending something) reaches the owner’s phone with two buttons, and every decision is logged with who, when and the result.
5. A second model from a different company that reviews what the first one did and flags disagreements. He does not say which one.
6. About 1,500 written procedures that the agents must consult before they are allowed to write anything. “The tooling enforces it: no procedure read, no write.”
7. Local models on the company’s own hardware for cheap, repetitive tasks: reading and classifying documents, building the library’s index and a first pass at code review. “Judgement stays with Claude.”
8. Backups four times a day, encrypted, in three places, restored on a clean machine every few weeks to prove they work.

Tools and architecture

Layer	What he uses	What it is for
Builder and operator	Claude Code	Writes and maintains the ERP; the agents run on it
Access to data	An in-house MCP server	The only door through which agents read and propose writes
Rules	~1,500 procedures, each with a date and a reason	The agent has to read the relevant ones before writing
Approval	Telegram with two buttons and a log	Every action with money, customers or production consequences
Second opinion	A model from another vendor	Reviews the first model’s work and flags disagreements
Cheap work	Local models	Classification, embeddings and a first code review only
Safety net	Separate test copy, tests, watchers, backups	Catch errors before and after they reach production

Two details from the comments complete the picture. Watchers: small scripts check the database, scheduled jobs, backups and every tax submission every few minutes; anything “doubtful” for more than a day, or any failed job, goes to the owner’s phone, and anything red for three days automatically becomes a proposal to fix it. And a “doubtful” state: if the connection to the tax service drops mid-request, the invoice stays without a final number and a watcher later repeats the same request to find out what happened. “It never re-issues blindly”, so a network cut cannot create a duplicate or a numbering gap.

Step by step to replicate it

This is our adaptation for a small company or a finance team that wants agents to work on its own systems. It does not require building an ERP; the same order works on top of a commercial ERP with an API.

1. Write the rules first. Pick one process (say, matching supplier invoices to purchase orders), write down how it is done and add a dated rule every time something goes wrong. In the author’s words, the procedures are for people; the AI just made writing them worthwhile.
2. Give the agent a narrow door: an MCP server that exposes only the reads and “propose” actions it needs, never the database.
3. Separate proposing from doing. Every write is a proposal a person approves on their phone, with a log of who, when and what.
4. Make reading the rules mandatory. The tool refuses a write if the agent has not loaded the relevant procedure; a polite prompt is not enough.
5. Two copies, two databases. Promote to production only what passed the tests on the copy.
6. Test the money logic with invariants (numbering, VAT, rounding, credit notes, retries, the signed chain) and run them before every change.
7. Add read-only watchers for pending documents, failed jobs, backups and tax submissions; anything ignored for days becomes a task.
8. One session per topic with a short hand-over note, and restore your backups on a clean machine on a schedule.
9. Check the tax rules before issuing invoices from a self-built system (see below).

Concrete example: the money tests

The most instructive part is a public exchange. A commenter, whose profile promotes a product that lets agents operate a computer, suggested four invariant tests; the author ran them on his test copy the same day. We summarise his report; the last column is ours.

Invariant	Result reported by the author	What it protects
Two real connections issue an invoice in the same series at once	Passed: the second gets “already issuing” without using a number, and on retry takes the next one	No gaps or repeated numbers
Change one byte of a stored invoice in a test copy	Passed after writing a chain verifier, checked first against a real chain registered with the tax service	Tampering is detected exactly at that record
A credit note plus the original sums to zero for each VAT rate	Failed for old invoices imported from the previous package with a header-level discount: one cent off in one VAT rate	Per-rate rounding, not just the total
Sending the same create request twice produces one document	Failed for quotes and draft invoices (supplier invoices and expenses already rejected duplicates)	Agents retry; retries must not duplicate

Both failures were fixed and in production that night, according to his follow-up. Credit notes for those discounted invoices now come out at exactly zero per VAT rate, and creating a document accepts an idempotency key: the screen sends one when the form opens, and agents send one built from the request content, valid for ten minutes. If a retry with the same content arrives after the window, it goes through but the owner gets a warning showing both documents. He had already tested retries of the same request to the tax service and that no two confirmed invoices share a number.

A second commenter, who sells reviews of AI agent set-ups, added a cheap idea worth copying: keep a few deliberately wrong documents (for example, five work reports with a known wrong price) and run the reconciliation step on them after every change. If any comes back approved, the change stops there.

Results stated by the source

All figures are the author’s and unaudited:

• He reviews about twenty agent decisions a day from his phone “in a few minutes”, and “nothing surprising ever happens”.
• A working session that kept the whole conversation was re-reading “hundreds of thousands of tokens on every step”; with one session per topic and a short hand-over note, “the same work now costs a fraction”.
• On seven real tasks from his backlog, a 27B local model scored 21 out of 52 against 46 for Claude. It does fine with a very short, precise plan and gets worse with more context.
• The mistakes he admits: when agents acted first and reported afterwards, the company “lost a day” to a batch of work reports approved with the wrong prices; and building once directly on production, a syntax error took the system down for a minute.

He gives no figures for hours saved, licence cost avoided, revenue or invoice volumes, and nobody else confirms the account.

The Spanish angle: a self-built invoicing system has obligations

The author does not name the regime, but what he describes (signed, chained invoices whose records are sent to the tax service) matches VERI*FACTU, the mode defined by the Spanish invoicing-systems regulation (Royal Decree 1007/2023). A few points from official sources that anyone tempted by this path should know:

• Software built for own use must also be certified. The Tax Agency’s FAQ says that if a company developed its invoicing software itself, the company must certify it by signing a responsible declaration under article 13 of the regulation. There is no external certification or prior registration; it is a self-certification included in the system.
• Each version counts. The same FAQ says each version, however small the change, is a different product that needs its own declaration. For a system that, as in this case, can go from comment to production in a day, that is real paperwork; ask your adviser how it applies to frequent releases.
• Issued records must not be editable from the system. The FAQ says changing issued invoicing records directly in the database must not be a permitted operation. The author’s design, where the database refuses changes after issue, points in that direction.
• Dates. On 5 October 2026 the Ministry of Finance announced it plans to postpone the pending VERI*FACTU obligations to October 2028, which still needs a formal regulation. Separately, mandatory B2B e-invoicing applies from 6 October 2027 to businesses with turnover above €8 million and from 6 October 2028 to everyone else. Businesses already in the SII immediate VAT reporting system are outside the invoicing-systems regulation, and the Basque Country and Navarre have their own rules.

None of this means the author is non-compliant; we do not know what he has signed. It means that building your own system makes you the software vendor in the eyes of the tax authority.

Limitations and risks

• Unverifiable source. One post and its comments, an anonymous company, a new account and a text written with an AI assistant. The specifics (tests, error, model scores) are coherent and self-critical, but they are not confirmed.
• Key-person risk. The author says it himself: “Expect to be the one maintaining it.” If he is unavailable, the company depends on a system only he and an agent understand.
• The approval loop is only as good as the reviewer. Twenty decisions in a few minutes is fast; it works if each card shows enough to decide, and if the canary documents above keep proving the checks still catch errors.
• Tests are new. By his own account, until that week the money tests did not run automatically before every change and there were none for cancellations, retries or the chain.
• Data. Invoices, payroll inputs and customer emails pass through a cloud model; decide what goes where and under which contract.

Common mistakes

• Letting agents act and report afterwards; it cost this company a day.
• Relying on the chat’s memory: “If it is not written in a procedure or a file, it does not exist the next day.”
• Testing totals only: the one-cent gap was in one VAT rate, invisible in the total.
• Assuming retries are harmless: without an idempotency key, the same request creates two documents.
• Building on production, and never restoring a backup.
• Giving small local models long tasks: in his tests they derail beyond a page.

Conclusions

This is not an argument for every small business to write its own ERP; the author’s own list of lessons reads as a warning about how much responsibility that implies, starting with the tax rules. It is, however, one of the most concrete accounts we have read of how to keep AI agents safe around money: proposals instead of actions, written rules the tool forces the agent to read, approvals on a phone with a log, invariant tests for numbering, VAT and retries, and watchers that turn ignored alerts into work. Those controls apply just as well to agents working on top of Holded, Odoo, Sage or any ERP with an API.