Portugal built its companies around the invoice

In 2025, 48.3% of Portuguese firms with ten or more employees used an ERP system. The EU average was 46.5%. In the same year, among the same firms, 21.6% used a CRM. The EU average was 28.5%.

The figures come from Eurostat, published in February 2026 (table isoc_eb_iip). Read together, they say something uncomfortable: Portugal installed more software for handling invoices than Europe did, and less for handling customers.

The gap between the two is 26.7 percentage points in Portugal and 17.9 across the EU. It is roughly one and a half times wider, and it holds across every size class with published data, including large firms. Between 2023 and 2025, CRM adoption rose 2.7 points in Europe and 0.8 points in Portugal. The gap is not closing. It is widening.

What those numbers describe is a country that built its companies around the one object the law required to exist. For decades that did not hurt, because there was always a person filling the hole. That person is now available for purchase as software, and the replacement fills nothing: it demands precisely what she was hiding.

More than half the firms measured have no ERP at all

Eurostat counts firms with ten or more employees, which means most people reading this are outside the sample entirely. The OECD puts 39% of Portuguese business employment in micro firms of up to nine people (Economic Survey of Portugal 2026, 6 January). Those firms do not appear on the chart at all.

And 48.3% ERP adoption means more than half the firms that were measured have no ERP. Among firms of 10 to 49 people it is 42.2%. This is not a portrait of a country full of badly used systems. It is a portrait of a country where most firms have no system, and where those that do installed mainly one.

Finally, correlation is not causation. Portugal having less CRM and lower productivity does not prove that buying CRM produces productivity. Portugal is in fact above the EU average on data analytics adoption (45.0% against 39.9%) and on ICT specialists as a share of employment (5.4% against 5.0%). The technical skill exists in the country. CRM is the symptom, not the cure.

The architecture did not fail, only the fiscal corner was ever compulsory

Any Portuguese ERP consultant would raise the obvious objection here, and would be right to. The domestic ERP vendors have had the full entity model for a long time. Customer, product, quotation, order, delivery note, job, contract. Nothing is missing from the software.

What failed is not the design. It is what got licensed, populated and wired up. And the only corner of that model that was ever legally compulsory is the fiscal one.

The chronology is easy to reconstruct. Portugal's SAF-T standard audit file for invoicing has existed since 2008. Tax-authority-certified invoicing software dates from a 2010 regulation, and is now mandatory for any business that turned over more than 50,000 euros in the previous year, for anyone already using invoicing software of any kind, and for anyone with formal accounts. A QR code has been compulsory on every invoice since 1 January 2022, a unique document code since 1 January 2023, and every invoice is reported to the tax authority by the fifth day of the following month.

None of this is irrational. It answered a real economic problem and answered it well. But look at what it asks for: it asks that the state be able to read the invoice. It never asked that the company be able to read what happened before it.

Twenty years of software investment driven by a legal obligation produces exactly what was asked for. Not one thing more.

The invoice is the terminal object of the business, and it was the only one given a home

There is a lazy version of this argument which says the invoice is not a business object at all, merely an output, sitting at the same conceptual level as a printed report or a shipping label.

That version is wrong, and an accountant will take it apart in two minutes. An invoice has a pre-registered series, a unique code, an immutable sequence, credit notes, a reporting deadline. It has more lifecycle than most things. And under Portuguese VAT, issuing an invoice does not describe a tax liability, it creates one. Outputs do not generate legal obligations.

The invoice is a genuine business object. The problem is that in most commercial cycles it is the last one. There are known exceptions, retainers, advance payments and pro-forma invoices, where it arrives before delivery. But in the typical sale, before it there was an enquiry, a conversation, a quotation, a negotiation, a job, a delivery, a complaint. Each of those has its own state, changes over time, and determines whether that customer ever generates a second invoice. None of them was ever legally required to live inside a system. So almost none of them does.

The Portuguese mistake is not ontological, it is topological. It is not treating a report as though it were an object. It is having built the company around the terminal object, because that was the only one given a home, and having left everything upstream of it living in WhatsApp, in Outlook, in PDFs and in people's heads.

One number closes this point with some force. In 2023, 24.5% of Portuguese firms sent invoices in a format suitable for automatic processing by another machine, against 38.7% across the EU. And 83% still sent paper invoices, against 70.2% in Europe (table isoc_eb_ics; the two indicators are not mutually exclusive, the same firm counts in both).

Every invoice in the country is reported to the state every month, and Portuguese firms still issue fewer machine-readable invoices than the European average. That is not a contradiction, it is the definition of the problem. What got digitised was the channel to the state, not the business. Paper, PDF and data are three different states, and swapping a filing cabinet for a shared folder is the same operation under better lighting. It is the same question already being asked of internal knowledge, and one that has since acquired a standard: where does it actually live, and can a machine read it?

For forty years, the adapter between the business and its systems was a person

All of this was equally true in 2015, and nobody died of it. Understanding why is where the only genuinely new thing lives.

Every company in the world has had, for decades, a compatibility layer running free of charge on top of a bad data model. That layer was a person. It is whoever knows that this particular customer always pays at 60 days even though the contract says 30. It is whoever reads the email, recognises it as a request for a quote, and fetches the price from a spreadsheet only they have. It is whoever connects what the systems do not connect, every day, without it ever appearing in a budget.

As long as the operator of the business was human, bad architecture carried a diffuse and deferrable cost. The human adapter has a property no software has had until now: it gives partial credit. It understands a badly worded request, infers what is missing, and asks when it does not know.

Saying that architecture matters is not new. Jeanne Ross wrote it in 2005 and 2006 and called it the operating model: the level of process integration and standardisation a company actually needs (MIT CISR). Eric Evans named the same problem on the software side in 2003, and Martin Fowler summarised it as bounded contexts. Twenty years of consultants have repeated it with steadily prettier slides, and almost nothing changed.

What changed in 2025 and 2026 is different: the adapter became purchasable. And the purchased adapter does not adapt. It demands exactly what the human adapter was concealing.

An agent does not operate conversations, it operates state

Ask an agent how many quotations are still open this month, what the average value is, and which ones have had no follow-up in ten days. If those quotations lived in WhatsApp and left as PDFs, there is no possible answer. Not because the model is incapable, but because no object called "quotation" exists anywhere. The information exists. It is distributed across three people's heads and one inbox.

The plumbing for the rest is already built. The Model Context Protocol, the standard defining how an agent discovers and uses an external system's tools and data, was opened by Anthropic on 25 November 2024 and moved to a neutral foundation under the Linux Foundation in December 2025. I wrote about how that protocol war ended here. What matters to someone running a small firm is not the protocol but who already exposes it: HubSpot's remote server reached general availability on 13 April 2026, with read and write access to contacts, companies, deals and tickets, and equivalent interfaces now exist, at varying stages of maturity, for project tools, customer support, payments and accounting.

Portuguese accounting data, by legal obligation, has been machine-readable since 2008. It was the first part of the business to get there, and in many firms it is still the only part.

Because an agent is simply a permanent new hire, one that never accumulates informal context and never has lunch with anyone.

The best agent in the best benchmark completes 30% of tasks

None of this means agents work yet.

TheAgentCompany, from Carnegie Mellon and others, set agents 175 tasks inside a simulated software company and was published at NeurIPS 2025. The most competitive agent completed 30% of them autonomously. Thirty.

On 25 June 2025, Gartner predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. It also estimates that of the thousands of vendors currently describing themselves as agentic, roughly 130 are real.

There is also a security problem that is structural and unsolved. Simon Willison calls it the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Combine all three and an attacker can talk the agent into sending them your data. He names the protocol explicitly, because it encourages mixing tools from different sources. The underlying problem is nearly four years old and still has no convincing mitigation.

Notice that this criticism does not undercut the argument, it supports it. The danger lies in assembling tools at random, without deciding what connects to what and with which permissions. When I gave an agent write access to my own blog, deciding the rules took longer than writing the code, and the rules were the work.

Which is why this argument has to pass one test: it must pay off with zero agents. And it does, because the question an agent asks of your business is the same one a new employee asks. If someone starts on Monday, how much can they learn on their own without asking anybody?

Structure the business and the agents fail, and you are left with a company that understands itself. Skip it and the agents work, and you have nowhere to put them.

Neither was ERP a mistake, nor is the answer eight subscriptions

It is not "buy eight tools". This is the easiest trap and the evidence runs against it. A MuleSoft survey of 1,050 IT leaders, fieldwork in late 2025, counts 957 applications per company with only 27% integrated, and 86% fearing that agents will add more complexity than value without proper integration. Those are large companies; among smaller firms, Okta counted 36 applications in businesses of up to 50 people in 2024, which is already plenty. Gartner itself warned about this in 2014, six years before selling the opposite: firms adopting postmodern ERP risk reverting to the complexities of a best-of-breed approach. And lock-in does not disappear, it relocates. It moves to the integration layer, and no integration platform fixes architectural ambiguity.

It is not "ERP was a mistake". It was a rational answer to a real obligation, and it remains compulsory: above 50,000 euros of turnover, certified software is not an architectural choice. The invoice becomes something generated at the end of a process rather than the start of one. It gets demoted, not replaced.

It is not "Portuguese firms are backward". The top 10% most productive firms in a Portuguese sector are 6.8 times more productive than the bottom 10%, against 4.7 in Spain (OECD Insights on Productivity: Portugal, February 2026, 2022 data). But the OECD is explicit that the dispersion is driven by a tail of low-productivity firms rather than a gap between the top and the rest. The Portuguese frontier is not weak. The tail is the problem, and the tail is large.

It is not "everyone should build custom software". Nor, at the other extreme, "buy the right suite and it is solved". Both are ways of purchasing an architecture instead of deciding one.

If the first step is free, why has nobody taken it?

The highest-return step in all of this costs nothing: writing down, on one sheet of paper, what the things in your business are and what states they move through. It is not an IT exercise. It is a management one.

If it is free and the return is real, why have more than a million and a half Portuguese firms not done it?

"Absorptive capacity" is the OECD's phrase for this, and it is a label rather than a mechanism. There is a better clue in a classic study of management practices (Bloom, Genakos, Sadun and Van Reenen, 2012, using data from the 2000s, so a structural portrait rather than a current measurement). Portugal scores at the sample average on monitoring (3.27 against 3.28) and poorly on target-setting (2.83 against 2.94) and above all on incentives (2.59 against 2.82, fourth lowest of twenty countries).

The shape of the problem is recognisable. Portuguese firms measure. What they do not do is set demanding targets and act on what they measured.

Naming your entities is exactly that. Writing down that a thing called a quotation exists, with states, makes visible how many are stalled and for how long. It creates accountability where there was comfortable ambiguity. Nobody gets paid for creating that. And in a fifteen-person company, the person who would have to do it is the same person doing the selling, on a Sunday night.

That is the real cost, and it appears on no invoice.

In a tree nursery, separating the taxon from the stock beat any software

The case that tends to convince a small-business owner fastest is not a digital one. It is an ornamental tree nursery where I ran a growth engagement. The catalogue treated as one thing what were really two: the taxon, meaning the name accepted by a botanical authority, and the yard stock, with calliper, height, container and batch. Before, "Acer palmatum", "Japanese maple" and the internal product code were three separate rows. Afterwards they were one record with three labels pointing at it.

What makes the story useful is not the normalisation. It is what happened to the rows that did not resolve. They were not deleted and they were not guessed at: they were flagged for a human decision, with the name of the person who had to make it. That is where you can see this is management work and not IT work. And it is a nursery, not a startup, which disarms the objection that this is a conversation for digital businesses.

The counterpoint comes from a two-sided US directory I have run for over a decade. It never had the invoice at its centre, and that allows something that looks small and is not: when a listing changes owner, the history stays with the listing and the billing relationship moves. If the invoice were the primary object, that would be impossible without rewriting history. In ten years the underlying vendors and payment processors changed several times. The entity model changed not at all.

One entity, one owner, one place

1. Name the entities. On paper. What the things in the business are and what states they pass through. It costs an afternoon and no money.
2. Decide where each one lives, and only one place per entity. There is a single rule: one entity, one owner, one place. This is where most architectures fail, and it is the difference between an architecture and a mess with a monthly invoice.
3. Capture state where it is born. A quotation that starts life in a form is already data. The same quotation answered over WhatsApp and sent as a PDF never quite exists.
4. Integrate last. Automation is the final layer. Without defined entities, it distributes the confusion faster.

And something that is true and costs me work: for most Portuguese firms the right answer today is not to buy a new architecture. It is to improve state capture with what is already there. A shared spreadsheet with a stable schema and one named owner beats a CRM that was bought and never used. Six in ten Portuguese firms do not use paid cloud services at all (38.7% do, against 52.7% in Europe, Eurostat, 2025). Prescribing eight integrated tools to a company at that stage is skipping two rungs.

Do the arithmetic before buying, too. Business software almost always charges per seat. Multiply by fifteen people and four tools, add the integration platform, and add all of that to the certified invoicing software and the accountant's monthly fee, neither of which goes away. The only part of this work with a guaranteed return remains the part that is free.

The advantage of being small is not agility, it is that there is no negotiation

In a large company the entity model is a political treaty. The definition of "customer" is contested between sales, finance and legal, and changing it is a programme with a sponsor. The expensive part of enterprise architecture was never the diagram. It was the negotiation. In a fifteen-person firm that negotiation is free and fits in an afternoon.

There is a less comfortable second half. A large company has a layer of people whose job is reconciling the misalignment between systems, and that layer absorbs the pain before it reaches whoever decides. A small firm has no shock absorber: the pain reaches the owner, on a Sunday. The incentive is clean, and it is the one structural advantage here that cannot be bought.

As for what comes next, two bets, stated as bets. The first is that lock-in changes character. Today the cost of switching vendor is mostly human, retraining ten people on a new screen. If nobody uses the screen, that cost vanishes and only the data remains, which improves the position of anyone who owns their entity model and worsens it for everyone else. Gartner has already put a number on the erosion of per-seat pricing: on 1 July 2026 it estimated 234 billion dollars of enterprise application spending at risk by 2030, around 20% of enterprise SaaS.

The second is that the gap widens before it closes. In a 2020 study of technology diffusion (Berlingieri, Calligaris, Criscuolo and Verlhac), the OECD showed that laggard firms converge more slowly precisely in the most digitally intensive sectors, because what they lack is not the technology but the intangible capital and skills that make it pay. A technology whose return depends on missing complements has always widened gaps first.

If you want to check my work later, here is the test. Portuguese productivity dispersion stood at 6.8 times in 2022. If the OECD's next measurement comes in above that, the widening happened. If it comes in below 6, I was wrong. And the Eurostat CRM number is no good for the test, because buying a CRM is not the same thing as having the customer as an entity.

For forty years, the compatibility between your business and your systems was maintained by someone who was never paid to do it. The replacement is now on sale, and it does not do that job.

The sheet of paper where you write down what a customer is remains the only part nobody sells you.