DEV Community

RWaltz Software
RWaltz Software

Posted on

Blockchain ERP Integration: The Failure Modes That Show Up After Go-Live

Most writing about blockchain ERP integration stops at the decision. Public or permissioned, which pattern, which platform, whether to proceed at all. That material matters, and it is reasonably well covered.

What gets far less attention is the part that determines whether the integration is still running two years later.

Integrations rarely fail on launch day. Launch day is the happy path: rehearsed, staffed by the people who built it, with a counterparty who is paying attention. They fail later, quietly, in the gap between a ledger that cannot be edited and an ERP that gets corrected every week.

This is a description of that gap, and of what to ask a delivery partner before you sign anything.

A pilot proves the part that was never going to break

A pilot demonstrates that an event can leave your ERP, reach a ledger, and come back. That path is the easy one. It is deterministic, it was written first, and it receives most of the test coverage.

The other paths define the system you actually operate. A transaction that never confirms. A counterparty submitting the same delivery twice with different batch numbers. A chain reorganization that invalidates a posting finance already made. A key holder who leaves the company. A period-end close that arrives while dozens of transactions are still pending.

If a proposal describes the happy path in detail and the exception path in a sentence, you are reading a demo plan rather than a delivery plan.

Two ledgers drift, and reconciliation is a system

The ERP is authoritative for internal state. The ledger is authoritative for shared state. They will disagree, and timing alone guarantees it: the ERP posts when a document is created, the chain confirms afterwards, and the window between them is where every discrepancy is born.

So reconciliation is not a script somebody writes at the end. It needs a drift detection job, an alert when the gap exceeds a threshold, a break queue with a named owner, and a documented rule for which side wins on each field. A break that nobody owns does not stay small. It sits there until an auditor finds it, at which point the discussion is no longer technical.

Immutability meets a business that corrects things

Enterprise life is full of reversals: credit notes, cancelled purchase orders, revised quantities, retroactive price adjustments. A ledger cannot accommodate any of them by editing.

What it can do is append a correcting event, leaving both records visible. That is workable, but it is a business agreement before it is a technical one. Your counterparty has to accept what a correcting event means, who may issue one, what evidence is required, and how the correction flows back into the ERP. Settle that before launch. Settling it during a dispute is considerably more expensive.

The same constraint explains why sensitive content should never be published in the first place. Publish commitments, keep the payload in systems where it can still be changed or deleted.

Key management is a rota, not a diagram

Architecture diagrams show a hardware security module. Operations shows a person.

The questions that matter are staffing questions. Does your signing quorum still function when two holders are on leave? Is offboarding a signer part of the same process HR already runs, or does it depend on somebody remembering? Is the operational wallet funded, and does anyone get alerted before it empties and stalls the pipeline? Has recovery been tested, or only documented? Can the team that deploys also sign, and should it be able to?

Map signing thresholds to the approval limits finance already uses. If the integration creates a parallel authority structure, you have introduced a control gap that internal audit will eventually find, and you will be explaining it under time pressure.

Compliance does not hold still after launch

If regulated transfers or tokenized assets are in scope, compliance is stateful, and it changes.

Identity-gated token standards such as ERC-3643 keep an identity registry and compliance rules onchain. That is a strong design, and it creates a permanent job: somebody issues claims, renews the ones that expire, revokes them when circumstances change, and keeps sanctions screening current. KYC and AML obligations do not end at go-live; they become a process with an owner and a response time.

Ask a prospective partner a plain question. On the day after handover, who performs that work, and what happens to a pending transfer when a claim expires underneath it?

Independent audit, then audit again

A single audit before launch covers code that stops existing at the first upgrade.

Treat review as recurring: an independent audit from a firm you can name, a published remediation record, a fresh review on any material change, a bug bounty for anything holding value, and upgrades behind a timelock so counterparties can see a change coming rather than discovering it. Ask for unresolved findings, not a badge on a slide. And do not assume a private deployment lowers risk. It lowers the number of people looking.

What the wrong tool looks like in the run book

Whether blockchain was the right choice is often clearer from the operating model than from the design document. Four signals:

  • No external party has any procedure for reading the ledger. If nobody consumes the shared record, you built an expensive write-only log.
  • Every exception resolves with "we will correct it in the ERP." That means the ERP is authoritative for everything and the chain is decoration.
  • The organization cannot staff support for it and does not intend to.
  • Master data disputes with the counterparty are still open, so the ledger is publishing disagreements permanently.

Two or more of these, and a signed API exchange, stronger audit logging or a simple hash anchoring approach will deliver most of the assurance at a fraction of the running cost. A delivery partner unwilling to say that out loud is not scoping honestly, and honest scoping is worth more to you than an enthusiastic one.

Own the keys, the repository and the exit

Ownership is an operational property, not a clause. On handover day, your organization should hold the signing keys and the ceremony documentation, the deployer and upgrade admin roles, the repository and the build pipeline, the audit reports and remediation history, the run book, the monitoring configuration, and the contract addresses with their provenance.

Build to own means the implementation partner is a replaceable operator. The test is simple: if changing partners would require redeploying contracts or reissuing keys, you never owned the system, whatever the contract said.

Ask for the second year, not the build

Before committing, ask a prospective partner to cost year two: node and RPC operations, monitoring, key custody, re audits, claim administration, exception handling, and who answers the phone. If they can only price the build, they have only planned the build.

The integrations still running in year three tend to be unremarkable. A narrow set of facts on the ledger, a reconciliation process somebody owns, a small group of key holders who practice their procedures, and a clear written list of the things this system is deliberately not authoritative for.

RWaltz builds blockchain and enterprise systems for regulated businesses, including asset tokenization, compliance-aware token standards such as ERC-3643, smart contract development, secure key management, and integration with existing systems of record. We scope honestly, put anything holding value through independent audit, and hand over the code, the repository, and the keys so clients own what they paid for.

📖 Read the full blog: https://www.rwaltz.com/blogs/blockchain-erp-integration-what-enterprises-need-to-know

Connect with RWaltz:

Top comments (0)