Ten years of OEM EDI: what we’ve learned running Bison Exchange for global car-carrier shipping

Most software vendors in the finished vehicle logistics space talk about EDI in terms of library count — how many OEM integrations they’ve connected to, how many message types they support. It’s a fair marketing claim and a reasonable shorthand. It isn’t the same as operating depth: how many years a system has actually run those integrations in production, against real OEM spec changes, real gateway migrations, real operational incidents.

We’ve been running Bison Exchange — production OEM EDI booking for global car-carrier shipping — for Siem Car Carriers for over ten years. It sits within the Bison Grid Ltd group as the third of our four production platforms (alongside BisonGrid, BisonPress and Bison Insights), and it’s a single-tenant deployment with one foundational customer. Multi-tenant productisation is a Year 2 candidate workstream for us, not a Year 1 priority — and we’ll come back to that openly at the end of the piece.

What follows is what ten years of operating it has actually taught us. It’s the kind of thing you only learn by living inside a production EDI system. Library count won’t get you there.

1. OEMs change specs more often than they’ll admit

The published OEM messaging standards — VDA in Germany, ANSI X12 in North America, EDIFACT internationally — are stable in principle and slippery in practice. A given OEM will publish a “minor revision” that, on close reading, alters the cardinality of a segment, the validation rules for a vehicle identifier, or the expected semantics of a status code. Each revision arrives with a deadline. Each one ripples through your mapping layer, your validation logic, and your downstream operations integrations.

A vendor doing a fresh OEM integration can map to the current published spec and call it done. A vendor running a ten-year deployment has a versioned record of every revision, the date it landed, the date it went live in production, and the regression cases that survived each migration. That’s operating depth. It’s the difference between “we support OEM X” and “we know what OEM X does on the third Tuesday of every month and have evidence to show for it.”

2. The integration test suite is the IP

The single most valuable asset in a long-running EDI deployment isn’t the production code. It’s the test suite that protects it. Ten years in, our suite of OEM EDI integration tests covers historical edge cases that nobody on the current team was around for — messages that broke in 2018 and shouldn’t break again, validation traps that took two days to diagnose the first time, gateway-specific quirks that only surface under load.

A new OEM integration without that test suite history is structurally riskier than one with it. You can hire experienced EDI engineers; you can’t hire a decade of accumulated regression coverage. This is one of the things we explicitly productise as IP, and it’s part of what a maintenance retainer around an EDI integration actually buys you.

3. EDI gateway migrations are the unsung horror

The conversation about EDI focuses on the message standards. The conversation that should also happen is about the gateways — the VAN providers, AS2 endpoints, SFTP drops, the modern API-EDI bridges — that the messages actually pass through. Gateways change. They get acquired, deprecated, repriced, or renamed. Each migration is a deliverable in its own right, and the cost of getting one wrong is silent message loss that surfaces a week later in OEM reconciliations.

Ten years of operating Bison Exchange means we’ve been through several of these. We have a documented playbook for gateway migration that didn’t exist when we started — built incident by incident, mostly the hard way. We charge for the playbook now. A fresh vendor doesn’t have one.

4. Audit trail is more valuable than throughput

There’s a thing that happens in OEM-side reconciliations: someone, somewhere, in 2022, sent a message that says one thing, and our customer’s records say something else, and the question is whose record stands. The answer in finished vehicle logistics is almost always: whoever has the audit trail.

We designed Bison Exchange around the assumption that every message — sent, received, retried, malformed, rejected — would need to be reconstructible years after the fact, with timestamps, hashes, transmission metadata, and the original payload preserved as raw as we could store it. It costs more to engineer that way and it costs more to store. The first time you win a reconciliation dispute against an OEM with hard evidence, the storage costs are repaid for the decade.

This is the bit that’s hardest to retrofit. A system that wasn’t built audit-first three years ago can’t become audit-first now without a substantial rework.

5. Conservative architecture ages better than fashionable architecture

Bison Exchange is not built on whatever was the most fashionable choice in 2014. It’s built on choices that were already boring at the time — well-understood messaging patterns, conventional relational storage, transactional integrity at the seams that matter, conservative use of async where it adds real value. Ten years on, the system is still a comfortable one to work in. Onboarding a new engineer to it is not a “tour of an obscure framework graveyard”; it’s a few days of reading code that does what it says.

We give the same advice to every operator looking at a new EDI build: optimise the technology choices for the team that will be maintaining the system in 2035, not for the architecture diagram on the pitch deck. If you can’t easily hire people who know the stack today, you definitely can’t in ten years.

6. What “production-grade” means in OEM EDI

The phrase gets used loosely. In our experience, production-grade OEM EDI for car-carrier shipping means at minimum:

• Idempotent message handling. The same message arriving twice doesn’t book a vehicle twice.
• Retry semantics that match the OEM contract. Different OEMs expect different retry patterns; getting it wrong looks like flakiness to the OEM-side operations team.
• Validation that fails loudly and early. A malformed message caught at the gateway is cheap; one that goes through and corrupts a downstream record is expensive.
• Operations-visible state. The current state of every active booking should be visible to your operations team in plain English, not buried in a log stream.
• Replay capability. When something goes wrong, you need to be able to replay messages from a known point against the current logic.

Each of those is straightforward to describe and non-trivial to actually deliver. Ten years of running Bison Exchange means each one has been tested against real failure modes. That’s the operating credential.

What the single-customer truth means in practice

Honest disclosure: Bison Exchange has one foundational customer. Siem Car Carriers. That’s a deliberate operating model, not a soft pipeline statement. The platform was built for them, has been refined with them, and runs in their operational environment.

Multi-tenant productisation — second-customer pipeline, marketing surface, published pricing — is a Year 2 workstream. We’ve held it back from Year 1 priorities for the same reason we held BisonPress back during its early development: we’d rather earn the right to a second customer with a hardened single-customer system than ship a multi-tenant version that’s been pressure-tested only by demos.

What this means for a car-carrier shipping operator evaluating EDI options today:

• If you want off-the-shelf software to buy this quarter, we are not currently the right answer. That’s a Year 2 conversation with us, or a vendor with a more mature multi-tenant product today.
• If you want a partner who has operated production OEM EDI for finished vehicle logistics for over ten years, with the test suite, gateway-migration playbook, audit-trail discipline and operating-depth credentials that come with that, we are a strong fit — for a Siem-pattern engagement scoped against your specific operational and OEM mix.

The honest framing of our position in the finished vehicle logistics software landscape: against the established vendors (NAPA, CargoTel, INFORM, ICL Systems VLMS), we don’t compete on geographic scale or recognised brand presence. We compete on the operating credential and the engineering depth behind it. That trade is the right one for some buyers. It isn’t the right one for all of them.

The line we use

Library count tells you what an integration vendor can connect to. Operating depth tells you what they’ve actually run, in production, through ten years of change. For OEM EDI booking in car-carrier shipping specifically, that operating-depth credential is rare. We’ve earned ours the only way it can be earned — by living inside the system, day after day, since 2014.

We build like operators because we are operators.

---

Bison Exchange is owned by Bison Grid Ltd. Team Bison is the trading name for the software, AI and operations consultancy within the Bison Grid Ltd group. If you’re a finished vehicle logistics operator evaluating OEM EDI options, we’re happy to walk through Bison Exchange on a Siem-approved demo environment. Get in touch.