In 2017 every ERP vendor announced a blockchain capability and almost no customer put one into production. That gap is the most instructive thing about the episode, and it repays examination because the reasoning errors made then are being repeated now with different technology. The pitch was coherent in the abstract. Enterprise systems spend enormous effort reconciling records between organisations — purchase orders against sales orders, goods received against goods shipped, invoices against payments, certificates against shipments. A shared, tamper-evident ledger would remove the reconciliation entirely, because both parties would be reading the same record rather than comparing their own copies. Trade finance, provenance tracking, customs documentation and multi-party logistics all looked like obvious candidates. What the pitch omitted is that the reconciliation problem is mostly not a technology problem. It is a consequence of organisations keeping separate records because they have separate interests, separate liabilities and separate reasons not to show each other everything.
The test that separates use cases from theatre
A distributed ledger is worth considering when four conditions hold simultaneously. Drop any one and a database with good access controls does the job at a fraction of the cost. Multiple organisations need to write to the same record. Not read — write. If one party owns the data and others consume it, an API and a permissioned view is the correct architecture, and it is what most "blockchain" pilots quietly became. No party is an acceptable custodian. If the buyer, the bank, the regulator or an industry body can hold the shared record and everyone accepts it, that is simpler, faster and cheaper. This condition eliminates most enterprise scenarios, because in practice a dominant participant usually exists and usually ends up hosting the platform anyway. Immutability has genuine value. Audit trails matter, but enterprise data gets corrected constantly — wrong quantity, wrong cost centre, reversed accrual. A ledger that cannot be amended requires a compensating-entry discipline that most operational processes are not built for, and treating an append-only structure as a benefit in a world of error correction is often a mistake rather than a feature. Participants will actually adopt it. This is where nearly every 2017 initiative died. A shared ledger is worth nothing with one participant, and network effects require the least motivated party in the chain to change their systems and processes for a benefit that accrues mostly to someone else. The use cases that survived that test were narrow: multi-party trade documentation where the paper process was genuinely slow and expensive, provenance in supply chains where a premium depended on verifiable origin, and certain letter-of-credit and bill-of-lading flows with a consortium willing to fund the platform. Everything else — internal audit trails, intercompany reconciliation, asset registers, supplier master data — was better served by the database the organisation already owned.
What the pilots actually taught
Three lessons that transferred, none of them about cryptography. The integration was the project. Writing to a ledger is trivial; keeping the ERP and the ledger consistent is not. Every pilot ended up building the same thing: a synchronisation layer with reconciliation logic to handle the cases where the two diverged — which is the reconciliation problem the ledger was meant to eliminate, relocated one layer down. Data quality became the binding constraint, immediately. A shared ledger makes your master data visible to counterparties. Organisations that could not agree internally on what a product code meant discovered that publishing it to a consortium was not an option. Several pilots were suspended not because the technology failed but because the data was not presentable. Governance was harder than engineering. Who admits new participants, who pays for the infrastructure, who arbitrates a disputed entry, what happens when a participant leaves, which jurisdiction's law applies to the shared record. These questions have no technical answer, and consortium initiatives that did not resolve them upfront stalled at exactly the point where they needed a second serious participant.
| Question | Evidence to request |
|---|---|
| Who must write? | Named counterparties that need shared updates |
| Who can hold the record? | Participants' acceptance of a custodian |
| Why preserve every entry? | Audit value and the correction process |
| Who will participate? | A funded adoption commitment beyond one organisation |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for ERP Blockchain Assessment
- Apply the four-condition test before any pilot. Multiple writers, no acceptable custodian, genuine immutability value, credible adoption — fail one and a permissioned database wins.
- Name the second participant before you start. A single-party distributed ledger is an expensive database with worse tooling and no network benefit.
- Cost the ERP integration and reconciliation layer explicitly. This is where the budget goes, and it is routinely excluded from business cases.
- Resolve consortium governance in writing first. Admission, funding, dispute arbitration, exit and governing law are the questions that stall projects, not throughput.
- Fix master data before exposing it to counterparties. Shared ledgers make internal data quality an external problem, quickly and permanently.
- Design the correction mechanism from the outset. Operational data gets amended; if your ledger cannot be amended, the compensating-entry process is part of the design, not an afterthought.
- Ask what breaks if you use a shared database with signed audit logs instead. If the honest answer is "not much", you have your architecture.
- Separate the vendor's roadmap announcement from a supported product. Ask for a named production reference in your industry before committing anything.
The Regional Dimension
The Gulf engaged with this technology more energetically than most regions, and for reasons that were not purely fashionable. Trade and logistics concentration is the genuine substantive case. Regional ports and transhipment hubs handle enormous volumes of documentation-heavy trade, and the paper processes around bills of lading, certificates of origin, letters of credit, customs declarations and inspection certificates are slow, costly and exactly the multi-party coordination problem a shared ledger addresses in principle. Regional customs authorities, port operators and trade platforms ran serious initiatives here, and some of the single-window and digital trade documentation work that followed delivered real efficiency — though frequently through platform consolidation and API integration rather than through distributed ledgers specifically. That distinction is worth noting carefully, because the benefit was often attributed to the technology when it came from the coordination. Government strategy was the second driver, and it changed the procurement environment. Emirate-level and national blockchain strategies made the technology a stated policy objective, which meant public sector tenders and quasi-government entities asked for it directly. For vendors and integrators that created genuine demand; for CIOs it created a specific difficulty — being asked to deliver a technology rather than an outcome. The defensible response was to satisfy the strategic requirement in the places where the four conditions actually held, and to resist retrofitting a ledger into internal processes where a database was correct. Third, the family-group and multi-entity structure that characterises regional business creates an internal reconciliation burden that superficially resembles the use case: many entities across mainland and free zone jurisdictions, intercompany transactions, transfer pricing, shared suppliers, and consolidated reporting assembled by hand. It is tempting to treat this as a distributed ledger problem. It is not, because all the entities have the same ultimate owner — which means an acceptable custodian exists by definition, and the answer is a single ERP instance or a group data platform with a common chart of accounts. Groups that ran blockchain pilots on intercompany reconciliation were solving an architecture problem with a consortium technology. Two further regional notes. The regulatory layer matured in a genuinely useful direction: Saudi e-invoicing clearance and the broader move to authority-cleared electronic invoicing across the region achieved much of what ledger-based invoice verification promised, by inserting a trusted authority into the transaction rather than distributing trust — which is the simpler and, as it turned out, more deployable answer. And data residency cuts directly against distributed architectures: a ledger replicated across consortium participants in several countries places copies of transaction data in each of those jurisdictions, which collides with Saudi PDPL and cloud framework requirements, UAE sector rules and government tender hosting conditions. That is a design constraint most 2017 pilots never reached, and it remains the least-examined obstacle to regional consortium platforms.
The objection worth taking seriously
The strongest counter to this scepticism is that the enterprise blockchain disappointment was a timing and tooling failure, not a conceptual one, and that dismissing the category entirely has costs. The 2017 platforms were immature: throughput was inadequate, developer tooling was poor, privacy models for permissioned networks were unsettled, and integration with packaged ERP was experimental. Several of those problems have been addressed meaningfully since. More substantively, some of what the technology promised did arrive through adjacent routes — digital trade documentation standards, tokenised settlement in specific financial contexts, verifiable credentials for certificates and licences, and authority-cleared invoicing. An organisation that wrote the whole area off in 2018 may have stopped paying attention to a set of capabilities that became relevant through a different door. There is also a fair criticism of the four-condition test itself: it is conservative by construction and would have ruled out most successful new technologies at their equivalent stage. Applied strictly, it says "use the database you have", which is usually right and occasionally means missing a genuine shift. Organisations in trade, logistics and commodities — where the multi-party documentation case is real — had a defensible reason to invest in learning ahead of proof, and some of them are now better positioned in digital trade corridors because they did. The balanced position: the test remains the right filter for production investment, but it should not govern exploratory spend. Learning budget and deployment budget are different things, and the 2017 error was mostly confusing the two — running pilots as if they were programmes, with steering committees and success criteria, instead of running them as cheap experiments with a clear kill condition.
Common Questions
Did any ERP blockchain use cases actually work?
Multi-party trade documentation, letter-of-credit and bill-of-lading flows with a funded consortium, and provenance tracking where verifiable origin supported a price premium. All shared the same features: multiple organisations genuinely writing to one record, and no single acceptable custodian.
Why did most pilots not reach production?
Adoption and governance rather than technology. A shared ledger needs other participants, and the party whose change effort is largest frequently captures the smallest benefit — so the network never formed. The unresolved governance questions then prevented the consortium from recruiting the participants that would have made it viable.
Is a private blockchain just a database?
In most enterprise deployments, functionally yes — a database with cryptographic audit properties and worse performance. That is not a criticism if the audit properties are what you need, but it should be costed and named accurately rather than described as decentralisation.
What is the lesson for evaluating AI claims now?
The same discipline, applied to a technology with far stronger underlying capability. Ask what specific problem it solves that your existing systems cannot, what condition would make it the wrong choice, and who has it in production at your scale. The 2017 pattern — vendor announcement, internal pilot with no kill condition, quiet abandonment — is repeating with AI features arriving in ERP release notes. The important difference is that AI usually delivers value within one organisation's boundary, so it does not face the network-formation problem that killed blockchain pilots; that makes adoption easier and evaluation discipline more important, because there is no external partner to force honesty about whether the thing works. Run experiments cheaply, define in advance what would make you stop, and require a production reference before anything becomes a programme.
ERP Blockchain Assessment — four conditions: multiple writers, no acceptable custodian, real immutability value, credible adoption. Fail one and the database you already own is the right answer.