AI in logistics, the SaaS apocalypse, and the invoice nobody checks

Fast code gets attention. In logistics, useful AI depends on the operating context behind each decision and whether teams can trust the result at scale.

And a few days before we launched nShift Audit, I sat down with our CEO, Jurgen Leijdekker, and Chief Product Officer, Johan Hellman, to talk about AI, logistics and where software is heading.

We recorded in the middle of a much bigger argument. Earlier this year, a run of new AI agent releases triggered a sharp sell-off in software stocks, and the term “SaaS apocalypse” quickly followed. Forrester was among those asking how much of the traditional software model survives when AI can produce working functionality at a fraction of the old speed and cost.

The Forrester analyst note is here: SaaS As We Know It Is Dead: How To Survive The SaaS-pocalypse!

The worry underneath it? If AI can write working code this fast, the software product you already pay for stops looking safe. The concern is understandable - if software can be built much faster, some of the assumptions behind SaaS have to change.

The logistics software industry puts that argument to a stress test: code is one part of the equation, but the software also has to understand what is happening across carriers, services, shipments and customer configurations, then make decisions people can rely on. This became the thread running through our conversation.

Nearly three decades of shipment data is the real AI asset

Jurgen's case for AI started with the complexity nShift and the companies it grew from have been processing since 1997.

“AI offered for us less of a threat and much more of a possibility to finally start mining that complexity.”

Every shipment behaves a little differently. Destination, carrier service, package details, delivery events, pricing and other conditions can all affect what should happen next. Across the 20,000 businesses that work with nShift, that creates a volume of operational detail no team could inspect line by line.

At scale, those small differences become difficult for a person to process one by one.

Johan came at the same problem from the product side.

“The challenge with logistics always comes from the scale, and from the lack of overview. You don't really know issues happen when you don't see end-to-end.”

Our platform's data fabric normalizes carrier feeds and delivery events into a structured format that can be used across nShift products. That gives AI something a general model does not automatically have: the carriers a company uses, how its services are configured and what happened to individual shipments. Johan put it this way:

“All those micro-decisions, a human couldn't do that, but an AI can. It can make all those small decisions. But AI is only as good as its context.”

For nShift Companion, that context comes from the customer's own nShift environment and shipping setup. A logistics team can ask about its operation without first teaching a generic assistant which carriers it uses, how those services are configured or how its shipping setup works.

The same context can support decisions that happen far more often than anyone could reasonably inspect one by one.

Useful AI has to work at scale, in real operations

Johan has a clear threshold for calling something a product:

“Product has always been about scale. It's not a product if it only works for one customer.”

That's a harder standard than producing a convincing demo that works once: real customers bring different carriers, agreements, file formats, workflows and exceptions. The system has to cope when the input is incomplete or unusual, and to give people enough confidence to use the result in an operational process.

Johan came back to trust several times during the conversation:

“If you deploy AI in your processes, you need to be able to trust it. So I think that's the trick. How can you deploy AI in a way that it is reliable, that you can trust what it does?”

That changes the role AI can play: a chatbot answer can be checked before anyone acts on it, while an AI system making thousands of small operational decisions needs controls around the data it uses, what it produces and what happens when confidence is low.

In logistics, those decisions can affect a delivery promise, a carrier choice or money leaving the business.

The invoice nobody could verify

Freight invoices put our argument to work by giving us a concrete example:

“Anyone who's seen a freight invoice or transportation invoice knows that that's almost impossible to say if it's correct,” Johan said.

A transportation invoice can contain many charges across shipments and services. The invoice shows what was billed and the evidence needed to check it could be hiding in a tariff, the original shipment record and later carrier events.

At any meaningful volume, checking everything manually becomes difficult. Sampling helps with errors that repeat consistently, but it's much less reliable for the occasional charge that appears on one shipment.

“Spot checks, of course, can find systematic errors, but they won't find irregular errors. We can't assume that you will happen to check that one line that was wrong.”

nShift Audit uses AI agents to read carrier invoice formats, match the information with other data and explain discrepancies in language the reviewer can understand. Johan described the change during our podcast:

“Now we know this can actually be solved with agents. You can actually read these formats, and you can actually match them with the data. And you can also, also important, you can use AI to explain why it's wrong. You don't have to be an expert to find issues anymore.”

The checks themselves are deterministic, while the AI handles work that previously made the process difficult to automate, including reading variable invoice structures and explaining the result. The invoice can then be checked against the tariff and the shipment record already held within nShift. That combination lets the audit run across every invoice rather than relying on a sample.

After we announced the new Audit solution, Johan wrote his own blog where he went deeper into the invoice checks, shipment data and dispute workflow. During our discussion the interesting part was, to me at least: how quickly the underlying idea could be proven, and what still had to happen before customers could use it.

Where the SaaS apocalypse argument gets harder

Jurgen framed the SaaS-apocalypse debate around functionality:

“There was always this discussion about the SaaSpocalypse, and that was all about functionality, meaning code can now quickly be written by AI. And so there's been an arc there of a bit of a panic and then a reckoning as to how important is domain knowledge, how much of a moat is there?”

The first working Audit prototype came together very quickly, and Jurgen recalled asking Johan about it:

“I asked you, 'How long did it take you?' You said, 'Probably about 10 hours over the course of two days.' And it looked really slick. To a layperson, it looked like a perfectly finished software product with a very good UX.”

In other words, the models could read and match the material well enough for the idea to work, but getting from there to a product that could handle real customers and real freight data took considerably longer.

“And then it takes another six months to go to the market, test it out, tweak it, cover the edge cases, make it scalable, make it secure, create the data layer that allows you to benchmark.”

The speed of the prototype is significant; AI has dramatically shortened the distance between an idea and something you can see working. But production brings a different set of demands: carrier formats and customer configurations vary, security has to hold, and edge cases turn up because real operating data is usually less tidy than test data.

To Jurgen’s point: 

“That is a far cry from saying, 'I also vibe coded this in two days and I'm done.' And I think that's the big disconnect today in technology land.”

That gap is easy to overlook when software is judged mainly by how quickly somebody can reproduce its visible functionality. The software still has to work with your carriers and data, make dependable decisions across real-world variation, and keep pace as the operation changes.

AI changes software, but logistics still has to work

The SaaS-apocalypse debate has already changed expectations around software development, and AI itself has changed the economics. Ideas can be tested faster, and internal tools that once needed a development project may take hours or days.

Businesses will reasonably ask whether every piece of software they buy still deserves to be bought. We believe that scrutiny is healthy.

For logistics software, much of the value exists beyond the visible functionality, so the answer will depend on more than how difficult the interface or functionality is to reproduce. And that's because a delivery operation accumulates context continuously, with carrier connections, services and agreements constantly changing. Amidst all this, your shipment data records what happened in practice, and every exception adds another case the software needs to handle.

AI becomes more useful when it can work with that operating context and apply it consistently across a volume of decisions no team could sensibly review by hand. When assessing AI in logistics, start with what the system already knows about your operation, then look at how it behaves as the data and configuration change, and whether the decisions it produces are ones you are prepared to trust.

The demo is only the beginning.

Watch the full discussion

Jurgen, Johan and I spend a little over 20 minutes on AI in logistics, the SaaS apocalypse, domain knowledge, trust and what separates a working prototype from software people can depend on. Watch the full discussion below, or on the podcast page, with our notes.

And if the freight-invoice example caught your attention, our next Solved webinar session puts it on screen: