The half-created order: why multi-entity writes are where AI-to-ERP projects quietly break

Most demos of AI writing to an ERP show the same thing: a single record, one entity, one field updated. It works, everyone nods, and the project moves to planning.

Then someone asks for the thing the business actually needs — "create the sales order" — and the demo stops being simple. Because a sales order is not a record. It's a header, its line items, schedule lines per item, partner functions, and pricing conditions. Five entities that only mean something together.

That's where these projects quietly break. Not on security, not on model quality — on the fact that creating a business document means writing several related records, and something has to guarantee they all land.

The failure that costs you an afternoon

Here's the sequence that shows up the first week a team enables multi-entity creation, usually built as a loop over separate API calls:

1. Create the order header. Succeeds. The ERP assigns number 48618.
2. Create the line item under it. Rejected — the material isn't extended to that sales org.
3. Stop.

You now have order 48618 in production: a header with no lines. It's not a valid document, it will never become one, and nothing about it is obviously wrong at a glance. Someone has to notice it, work out that it's an artifact of a failed AI call, and delete it manually — assuming the ERP even lets them delete it, which for many document types it doesn't.

Do that a few times and you've taught the business a lesson that's very hard to un-teach: letting AI write creates cleanup work. The project goes back to read-only, and the value case goes with it.

The deeper problem isn't the failed call. It's that partial success is worse than clean failure. A write that fails completely is an error message. A write that half-succeeds is corrupt data, and corrupt data is somebody's afternoon.

Retries don't fix it, and neither does "just delete it"

Two instincts show up here, and both make it worse.

"Have the AI clean up after itself." Now the compensating delete is itself an unreviewed write to production, running at exactly the moment your system is in a state you didn't anticipate. If that call fails — permissions, document locked, status already past deletion — you've turned one orphan into an orphan plus a failed cleanup, and the error message is now about the wrong problem.

"Retry the whole thing." Retrying a document creation that partially succeeded is how you get two orders. The header call has no idea 48618 already exists.

Both instincts are attempts to fix at the application layer something the data layer is supposed to guarantee. Which it can — this problem was solved decades ago. It's called a transaction, and the protocol your ERP already speaks has one.

The fix is a transaction, not cleverness

OData — the protocol behind SAP's public APIs, Dynamics, Business Central, and most modern ERP interfaces — has always had a way to say "these writes are one unit of work." Send the document as a single transactional request and the server does what servers are good at: if any part is rejected, the whole thing is rolled back. No header. No orphan. Nothing to clean up.

The error you get back is now the only thing that happened. Fix the material, run it again, get a clean order.

This changes the risk conversation entirely. "What happens when the AI gets it wrong?" stops being a question about damage control and becomes a question about error messages. The worst case is you read a sentence from your ERP and try again — the same worst case as a person typing the order by hand and getting a validation error.

The engineering, to be fair, is not free. Doing it properly across systems means handling the parent-child key problem (the line item needs an order number the ERP won't generate until the header is created), differing transactional mechanisms between OData V2 and V4, and vendor quirks in what each service actually supports. It's a few weeks of specialist work you only want to do once — which is the general argument against building your own MCP server, in miniature.

What good looks like from the operator's seat

Three properties are worth insisting on, whether you buy this or build it:

All-or-nothing, by default, per tool. Atomic should be the setting you choose once when you configure the tool, not a flag someone remembers to pass at call time. Step-by-step processing has real uses — long documents where you want visible progress — but it should be the deliberate exception.

Errors attributed to the row that caused them. "The request failed" is not actionable when a document has fifteen line items. You want to see which entity was rejected and the ERP's own message, so the fix is obvious. Attribution across a single transactional request takes real work to do well, and it's the difference between a usable error and a support ticket.

The result read back per entity. On success, every part of the document should report the keys the ERP assigned — the order number, each item number. That's what makes the next step possible, whether the next step is an AI follow-up call or a person opening the document.

And all of it still sits behind the same approval gate as any other write. Atomicity answers "what happens if it fails halfway?" It doesn't answer "should this happen at all?" — that's the reads flow, writes wait model, and you want both. A human approves the document; the transaction guarantees the document lands whole or not at all.

Why this is the unlock, not a detail

It's tempting to file this under implementation trivia. It isn't. Multi-entity writes are the boundary between AI that answers questions about your ERP and AI that does work in it.

Every transaction that matters — a sales order, a purchase order, a goods movement, a service entry — is a document with parts. If your platform can only write one record at a time, AI stays a reporting tool with extra steps. If it can write a document safely, the daily work of a sales desk or a procurement team is in scope.

The question worth asking your vendor, or yourself, isn't "can it write?" It's: when the third line item is rejected, what's left in my system?

The right answer is nothing.

---

DataTether's composite tools deliver multi-entity writes with all-or-nothing safety, per-source results, and approval gates—documented in our multi-entity writes guide. To see it against your own document types, request guided access.