Booking Goods Receipt and Shipping with AI: with Preview and Approval

There is a point at which enthusiasm for AI in the ERP reliably tips, and it sits almost exactly at the warehouse gate. A quote that the AI creates wrongly, you fix in two minutes. A warehouse booking, you don't. It moves stock, it creates documents, it is tied to batches and serial numbers, and if things go badly, the parcel is already at your customers' while you're still wondering what actually happened.

We have been building weclapp integrations for retail and production since 2019, as a certified weclapp partner from Vienna, and on our platform wals.pro AI 4 weclapp we now see over 5,000 AI actions in 30 days from real customer tenants. Four out of five of them are read-only: checking stock, searching sales orders, pulling reports. It gets interesting with the last fifth, which actually writes. That is exactly what this is about, and about why with us not a single goods movement is booked without you having seen and approved it beforehand.

Goods receipt starts with one sentence

The entry point is unspectacular, and that is precisely the point. You tell your AI assistant in plain language what has arrived: "Book the goods receipt for purchase order BE-2041, line 1 in full, line 2 only 40 pieces, delivery note 88213." The platform then looks up the purchase order, checks its status, assigns the line items and builds a plan from it that you get to see before anything is written. It states which purchase order is affected, which line items with which quantities, which storage location is used, which batches or serial numbers are attached, and whether stock is put away in the end or not.

Much of this you don't have to specify at all. For batch-managed items, you can pass along a batch including expiry date or split a line item across several batches; for serial-number-managed items, you name the specific numbers and the quantity follows on its own. If the rest of the purchase order only arrives next week, the platform continues the same open goods receipt instead of placing a second one next to it. And without a storage location specified, the stored default simply applies.

One thing, on the other hand, deliberately does not happen on its own. If the purchase order is still in draft, the AI can confirm it, but only if you additionally agree explicitly that an automatic order confirmation goes out to your suppliers in the process. This switch is off by default, because nobody should have to find out afterwards that a warehouse booking triggered mail to suppliers on the side.

The outbound side gets more interesting

Shipping works in principle the same way, only with considerably more moving parts. Behind a sentence like "Ship sales order AU-3312, line 3 with serial numbers SN-9 and SN-10, tracking DHL-4711" lies a whole chain: the delivery is created or an already open one is reused, every line item is picked and in doing so pulls its serial numbers, batches and storage locations, the status moves from New via Delivery note printed to Shipped, and right at the end the tracking number lands in the document.

How precisely you address the line items is up to you: via the sales order line, via the line number, via item number or item name. If the assignment becomes ambiguous, the preview aborts and asks, instead of deciding on one variant. The date logic is similarly strict: it rejects a shipping date in the future and likewise a delivery date before the shipping date. Both are mistakes that are surprisingly easy to make in the screen.

The problem that made over-delivery protection necessary

That brings us to the detail on which this whole feature hangs.

weclapp behaves when picking in a way you should know about: if a delivery line is under-picked, the system silently raises it back to the full line quantity during picking. So if you create a delivery for ten pieces and pick only two, you still end up shipping ten. There is no error message and no query. The stock is booked, the delivery note states ten pieces, and the missing eight can no longer be delivered cleanly from the sales order.

Over-delivery protection steps in right before that: for a partial delivery, the delivery's line quantity is lowered first and only then picked. Two of ten stay two of ten, and the remaining eight stay open and deliverable in the sales order.

Around this lie further safeguards, all of which take effect before the first write operation. If you simply say "ship the sales order" for a multi-line order, nothing happens at first: you have to confirm separately that really all open line items should go out. Serial- and batch-managed line items can't be shipped along this way anyway, because the platform fundamentally does not resolve serial numbers from stock on its own, but requires you to name the line item. And where a quantity exceeds the sales order line, stock is missing, a storage location is ambiguous or a document has long been closed, the process aborts with a clear message instead of leaving a half-written document behind. Even between two write steps, the platform reads the document in again authoritatively and compares it with the approved plan. If it deviates because someone worked in the interface in parallel, it stops.

If something does go wrong

There are two paths for corrections, and the difference matters. Rework resets a delivery to New and is the path for header data: a wrong shipping date, a wrong delivery date, a missing tracking number. If the delivery was already shipped, the line items stay locked in the process because the stock movement has already been booked. So you correct the header and send the document straight back to Shipped.

A cancellation, on the other hand, makes the delivery permanently invalid. It can neither be reactivated nor edited afterwards, and if it had already been shipped, it is first reset and then cancelled. If you want to deliver after all, a new delivery is created. The rule of thumb we give customers is therefore: header data wrong, then rework. Content wrong, then cancel and deliver anew. Which of the two happens, you see in the preview before you approve.

The same principle, by the way, also applies away from documents, i.e. for inventory differences, breakage, found stock or transfers between storage locations and warehouses.

Two steps and a token

Technically, approval is built identically for every write operation. The first step is the preview, and it changes nothing: it delivers the complete plan with all individual steps, all warnings and all resolved default values, plus an approval token.

The second step is the execution, and it works exclusively with exactly this token. It is bound to the action, to the target document and to a SHA-256 hash of the payload, which is why even a single changed character in the payload leads to rejection. The token is short-lived and valid once, and anyone who redeems it a second time gets the logged result of the first run back instead of booking again. Double bookings through a hasty second click or a network timeout are thus ruled out.

In short, and this applies to the entire platform: the AI never writes unasked. Preview, approval, audit trail.

What customers say

"A game changer for weclapp."

Kurt Liebenberg, Managing Partner at BQM

"I bow deeply."

Karl Heinz Hermann, Managing Director at Das gesunde Tier

How to get started

You don't need much: a weclapp tenant, an AI assistant of your choice and access to wals.pro AI 4 weclapp, which currently runs in open beta and is free to use until 12/31/2026.

The quickest way is the 90-second demo on goods receipt. After that, you set up a free beta account and run through the first booking in your own test tenant: ai.wals.pro

And if you want to see what this looks like in your warehouse specifically, with your batches, your serial numbers and your storage locations, then book 30 minutes with us: wals.pro/termin