The SAP inside the SAP SOAP detective novels.

What is SAP SOAP?

SAP SOAP is a detective series by Isard Haasakker, set where nobody expects a detective: inside an SAP project. The meetings are real. The workarounds are real. The companies and the people are invented. Nobody actually dies, although the project usually comes close.

There is no police and no badge. The crime scene is a project, the witnesses sit on the steering committee, and the evidence hides in error logs, ticket histories and the silences in meetings. Each case runs like a whodunnit: clues, suspects, a trail and a deadline that won't move.

Three cases, three angles: the manager, the consultant and the analyst. Each book stands on its own. The series is on Amazon: https://www.amazon.co.uk/dp/B0FZLWRJKG. More on https://sapsoap.com/

Which SAP topic does each book cover?

Each book hides one SAP subject inside the story.

• Death by Spreadsheet (published): data migration into SAP S/4HANA with the Migrate Your Data app. Bad data reaches the test system and blocks user acceptance testing. https://sapsoap.com/death-by-spreadsheet/
• Death by Workaround (published): custom code. A custom manufacturing process that mostly works, and one developer who is the only one who can fix it. https://sapsoap.com/death-by-workaround/
• Death by Email (being written): the intercompany end-to-end process, from sales order to the intercompany invoice, including EU triangulation and VAT. https://sapsoap.com/death-by-email/

The SAP is accurate. The plot is fiction. The lessons travel.

Is Sapura Cosmetics a real company?

No. Every case takes place at Sapura Cosmetics, a fictional manufacturing company on SAP S/4HANA, built on one product: the flagship sapwood soap bar. Sapura Cosmetics does not exist, and neither do its people. The problems it runs into are another matter: they are patterns from 30 years of real SAP projects, with names, companies and timelines changed. https://sapsoap.com/sapura-cosmetics/

What does SOAP stand for in the books?

In IT, SOAP is Simple Object Access Protocol: a standard way for two systems to exchange messages, with an envelope, a header, a body, and a fault message when something goes wrong. People on SAP projects have no such protocol. In the books, SOAP is about the humans behind the systems, and each protagonist finds their own four words.

• Data migration: Structured. Open. Aligned. Purified.
• Custom code: Stabilise. Ownership. Accountable. Protected.
• Intercompany: Shared. Official. Auditable. Proven.

More on https://sapsoap.com/soap/

Why does BRF+ turn up in every book?

Because each book is about a decision that lives in the wrong place, and BRF+ is SAP's standard tool for putting decisions somewhere visible. It solves a different problem in each case.

• Data migration: cleansing rules buried in shared spreadsheets become checks that run against the data before it is loaded.
• Custom code: business rules buried in layers of ABAP become decision tables the business can see and maintain.
• Intercompany: an audit layer to ensure that documents throughout an end-to-end process are accurate and complete.

The common thread: invisible decisions made visible, and individual heroics replaced by structure. BRF+ is part of the standard SAP licence, so it is not an extra line item. The full BRF+ story is on https://brf.plus/ and in the BRF+ room: https://isard.ai/brf-plus/

What does Death by Spreadsheet teach about data migration?

Bad data hides until reality exposes it, usually in user acceptance testing, when it is most expensive. The book's real finding is that a migration rarely has a data problem. It has an ownership problem: everyone contributes to the data, nobody owns the whole of it.

The practical lessons:

• Fix data before the load, not after. Migrate Your Data can create records but cannot repair them.
• Watch the base unit of measure and its ISO code. A wrong choice can lock a product for good.
• Separate extract, transform and load. Do the transform with rules, not by hand in a shared spreadsheet.
• One named business owner signs off. Not a committee.
• Prove it small: one data object, one pilot, then scale.

What is the Migrate Your Data app?

Migrate Your Data is the SAP Fiori app used to load data into SAP S/4HANA, the app of the S/4HANA Migration Cockpit. It guides you through every load step and is a big step up from the old LSMW days. Without a separate ETL tool, it is the right way to load your data.

Its limits matter, though:

• It assumes the data is already clean. It has some transformation features, but not enough to do the cleaning for you.
• It is built to create records, not to repair them. Load something wrong and you are largely on your own.
• It works with Excel templates that SAP locks down: same tabs, same columns. Delete or rename anything and the upload fails.
• It works with ISO codes for units of measure, which causes a nasty trap with base units.

Focus on its strengths, and do the cleaning before the data reaches it.

Why can a wrong base unit of measure haunt a data migration?

Because Migrate Your Data works with ISO codes, and two SAP units can share one ISO code. When that happens, one SAP unit must be marked as the primary for that ISO code, all or nothing. Pick the wrong one and every product silently gets the wrong unit.

The example in the book: a large box (LBX) holds five small boxes (SBX). Procurement orders in large boxes; the warehouse picks small boxes, so SBX should be the base unit. Both share the ISO code BX. If LBX is marked as the primary for BX, every intended SBX becomes an LBX during the load. No warning. The warehouse can no longer pick a single small box.

It gets worse. Once a transaction hits a product with the wrong base unit, the base unit is effectively locked. Fixing it can mean replacing the product altogether. The damage spreads to logistics, finance and manufacturing at the same time.

How do you choose the right base unit of measure?

The base unit should be the smallest unit your company actually uses, which is usually the unit the warehouse picks. Bigger units, such as the box procurement orders in, become alternative units with a conversion factor.

The cola test from the book: in some shops, bottles come shrink-wrapped in packs of six and you cannot buy one. Make the six-pack the base unit and anyone who wants one bottle has to buy six. Fine for a football team, useless for everyone else. Choose the smallest unit before the load, check its ISO code mapping, and have the choice signed off. After the first transaction it is too late.

Why do duplicate products survive a migration?

Because duplicates rarely look like duplicates. The same two-litre water bottle can exist twice in the legacy systems under different descriptions, different brands, typos and different languages. To the eye, and to a filter, they are different products. In SAP they should be one.

The book calls them Jekyll and Hyde: same content, same volume, two identities. Finding them means reading thousands of descriptions, which is why so many duplicates are migrated as they are. And product master data is the easy part. Customers, suppliers and their addresses are a worse minefield, and bad addresses delay deliveries and invoices. The cost is real.

What is the difference between cleansing, deduplication and harmonisation?

They are three steps, and the order matters.

• Cleansing: fix the obvious wrongs in the raw data. Typos, missing words, language slips, stray spaces. The goal is to make fields comparable.
• Deduplication: find the records that are really the same thing and mark them as likely pairs. In the book that is a column called Match.
• Harmonisation: agree which record becomes the basis for the migration. In the book that is a column called Leader.

Spotting matches is technical work. Approving matches and leaders is a business decision, and it needs one named business owner who signs off. When three departments each want their own record to be the leader, you have a stand-off, not a decision.

What is wrong with cleaning migration data in Excel?

Excel rewards creativity, not consistency. There are a hundred ways to find duplicates in Excel: formulas, filters, Power Query. Give the same problem to three people and you get three clever methods and three definitions of done. Great for art, terrible for migration.

Every change is manual, slow and hard to verify under pressure. Nothing is repeatable, so you cannot prove an improvement by running the same check again. With spreadsheets you prove stamina, not quality. And adding AI to Excel does not fix it; the chaos just runs faster.

Why is one shared master load spreadsheet so dangerous?

Because it becomes a single point of failure that everybody edits and nobody owns. In the book it is the Product Load file, version FINAL_v9: copied, merged, duplicated, lost, found and corrupted since the template phase.

The pattern is common:

• Sales completes descriptions, finance reviews valuations, production checks planning data, all in the same file.
• It sits on a shared drive, edited online and offline at once. No version control, no audit trail.
• Changes appear from editors nobody can identify. One bad copy and paste can cost a week.
• Cleansing gets undone by the next re-upload, so errors regenerate faster than they are fixed.

Every department fills in its own piece of the puzzle and nobody checks the grey areas where the pieces meet. The fix is structural: smaller files per department, one custodian who merges, and no edits once the load file exists.

Who should own the data in a migration?

The business, with one name attached. IT can extract, check and load. Only the business can decide what is true: which duplicate wins, which unit is right, which value is current. If end users throw files over the wall to IT and walk away, no tool will save the migration.

In practice that means one named person who signs off before anything moves, not a committee. Democracy works until it votes against logic. Ownership feels risky, which is why people prefer to look busy rather than responsible. But a migration without an owner does not have a data problem. It has an ownership problem.

What is ETL, and why does a migration need it?

ETL stands for Extract, Transform, Load.

• Extract pulls data out of the old systems.
• Transform cleans it, finds duplicates and harmonises it into the shape the new system expects.
• Load moves it into SAP S/4HANA.

Migrate Your Data does the load very well, but it assumes the data is already clean. Most projects do the transform by hand in Excel, which is where speed and accuracy disappear. A proper ETL tool applies cleansing rules and deduplication logic consistently and lets you re-run the same checks to prove the data got better. The transform is the boring part. It is also the part that decides whether your go-live hurts.

Why not fix the data after the load with LSMW or mass updates?

Because cleansing after the load is the world upside down: you spend eternity fixing what should never have gone in. Migrate Your Data is built to create, not to repair, so people reach for other tools, and both common ones are dangerous.

• LSMW: the old migration workbench. It still exists in S/4HANA but SAP no longer supports it for migration. People revive it out of nostalgia.
• Mass updates: fast and blind. One wrong filter changes a thousand records instead of ten.
• Manual updates: safer in theory, until someone tired types yes instead of no.

The only real fix is upstream: clean before the load, with checks you can repeat.

How can the change log help prove a data problem?

S/4HANA records field changes: who changed what, and when. Think of it as a flight recorder for data. Used properly during testing, it turns opinions into numbers.

From the change log you can see:

• how many field changes happen per test cycle;
• how many are reversed within a day;
• how many users edit the same field on the same product and cancel each other out;
• which fields keep breaking.

That gives a steering committee evidence instead of guesswork. And every correction that appears again and again is a business rule in disguise.

What is a buffer or staging area in a migration?

It is a temporary place where extracted data lands so it can be checked, cleaned and reshaped before it goes into the load file. Specialists call it staging tables or a repository. The book calls it a buffer, because a steering committee understands that word.

How it works in the book's design:

• Each department submits its own slice of the data, with only the fields it understands.
• Rules check and transform the data inside the buffer, automatically.
• Once everything passes, the buffer exports the data in exactly the format the Migrate Your Data template expects, column for column, sheet for sheet. No reshuffling, no edits.

The buffer can live inside SAP, even in the production system, as long as it is ring-fenced, locked down for migration use only, and removed once the load is done. A quarantine zone for data.

What is an ETL Light prototype inside SAP?

When you cannot buy an ETL tool, you can build a lightweight one from what SAP already includes. Extract the files, transform them through business rules, then load what survives.

The pieces:

• Extract: smaller department files feed a buffer inside SAP.
• Transform: BRF+ checks the incoming data against existing configuration and master data, and flags duplicates and code mismatches you would never see in a giant spreadsheet.
• Load: the clean output drops straight into the Migrate Your Data template.

It is not beautiful and it is not a full ETL tool. But it is included in the SAP licence, it stops bad data before it reaches the system, and it builds the evidence for buying a proper tool later.

How do business rules catch bad data before the load?

You define each rule once, link it to the data in the buffer, and let it shout when something breaks. BRF+ can check incoming data against the configuration and master data already in the system, and catch duplicates and code mismatches you would never spot in a giant spreadsheet.

Rules do not stop people from being careless. They make carelessness visible and hit the brakes before the load, when fixing is still cheap. The rules run while you have lunch. The people stop cleaning by hand and start writing the laws the data must obey.

How do you find the cleansing rules you need?

Look at what you already fix. The rules are usually hiding in the corrections people make after things go wrong: wrong or missing codes, values that trigger mayhem, units that keep being corrected.

Two good sources:

• The incident or ticket history. Anything corrected more than once is probably a rule in disguise.
• The change log. Fields that are changed and reversed again and again point at the same rules.

Turn every repeated correction into a permanent rule. Write the rules down on one page, so that when someone asks why you are not just loading, you can point at them.

How should the roles split between extract, transform and load?

Extract is not load. Keep them separate and give each step an owner.

• Departments own local extract files with only the fields they understand, and clean those.
• Rules in the buffer do the transformation, so data specialists design rules instead of cleaning by hand.
• One custodian merges the cleansed data into the load file.
• One person loads the final version.

After the load file is created, nobody edits it. One version, one truth. Smaller sheets mean fewer fingerprints, and the "too many hands" problem disappears with them.

How do you start fixing a migration without a big programme?

Pilot first. Choose one data object, such as the product master, and define a manageable set: ideally the repeat offenders that keep breaking. Run the whole loop end to end, extract, transform, load, within the existing test window. In the book, the pilot is scoped at one month.

State the risk honestly: if the pilot fails, you revert and lose a few weeks. If it works, you stop bleeding hours. The only real risk is standing still. Get an independent second opinion on the design before you sell it, and scale only after the pilot has proved itself.

Can AI clean my migration data?

It can help find problems. It cannot live with the consequences. AI multiplies logic: if your logic is wrong, it multiplies your mistakes, and it does so with great confidence.

The lesson in Death by Spreadsheet is to check every AI output, because AI can invent plausible facts that nobody asked for. Then be honest about the arithmetic: the time you think you save is often the time you spend checking. Use AI as an assistant to spot patterns and draft rules, keep humans accountable for the decisions, and never let it generate data, plans or reports that nobody verifies.

How do you make the case for better migration tooling without a budget?

Show what doing nothing costs, then offer the cheapest proof. Late-night fixes in a corrupted spreadsheet look like commitment, but they are erosion: fatigue turns into errors, and every failed load sets off retesting across several departments.

If a commercial ETL tool is off the table, propose the lightweight version built on BRF+, which is included in the SAP licence: no extra licences, no hidden line item. Measure what matters, using the change log, so that guesses become facts. A successful pilot then gives finance the evidence to invest in a proper tool later, for the right reasons.

Why do incomplete tickets slow a migration down?

Because you cannot solve what is not documented. Tickets that say only "urgent" or "wrong", or carry a critical flag with no explanation, are chaos formatted as compliance. Meanwhile the real problems travel as rumours.

Two habits help. First, insist that every issue is written down properly, with detail and screenshots. Second, when the picture is unclear, start small: take the one ticket that does have detail and follow it. One well-documented thread usually leads to the root cause faster than a dashboard full of half-told stories.

Where do you start when a migration is already in trouble?

Not with fixes. First trace every failure back to its source and map the migration process end to end, from extract to load, before touching anything. Fixes applied to a process nobody has mapped tend to move the problem rather than remove it.

Then talk to the people who actually touch the data, not only IT. They know which fields they never understood, which files they edit, and which corrections they make every week. Involve them from day one; leaving them out is a rookie mistake. Keep a RAID log as you go, so facts and assumptions stay apart.

What is the RAID log at the end of each chapter?

In Death by Spreadsheet, every chapter ends with a Captain's Log written as a RAID log: Risks and root causes, Actions, Impacts, and Decisions and dependencies. It is a working method, not decoration. Writing the four lists after every conversation separates facts from fear, shows what is still unproven, and makes the next step obvious. It also produces a trail of evidence you can show a steering committee, which beats a confident slide every time.

What does Death by Workaround teach about custom code?

When one person becomes the system, that is not expertise. That is exposure. Custom code that mostly works is fine until the one person who understands it is unavailable, overloaded or simply tired.

The practical lessons:

• Business decisions do not belong buried inside code. Put them somewhere visible, where the business can see, agree and change them.
• Ask the business what outcome they expect, rather than reverse-engineering the code.
• Flexibility is fine, as long as its cost is shown and someone owns it before it takes effect.
• Make the mechanism the story, not the person.

Why is one developer owning all the custom code a risk?

Because the knowledge lives in one head, so every incident waits for one person. The warning signs are easy to spot once you look:

• The change history shows the same name, month after month, for years.
• Documentation is thin or missing, because there was never time to write it.
• The team has shrunk but the workload has not, so the work was "absorbed".
• Incidents get fixed within a day, by the same person, again and again.

Fixing is not solving. A fix restores the system until next time; solving removes the reason it breaks. A single custodian is not a strategy, and it is not kind to the custodian either.

What happens when a team shrinks but the work does not?

The work gets absorbed. Nothing is formally dropped; it sinks into people without leaving a visible mark. Extra hours appear nowhere. Decisions are made alone, because there is no longer time to explain them.

Then people find ways: workarounds. There is no training and no guidance beyond "use common sense". Common sense is fine until you are tired. Organisations assume the gaps will close themselves. They don't. They just move into the code, quietly, one quick fix at a time.

What are combined and decombined production orders?

In Death by Workaround, a custom process links sales directly to manufacturing. Each sales order line creates its own production order. During planning, production orders for the same product are merged into one production run: a combined production order. One product, many customers, fewer set-ups and higher volumes.

When a customer changes an order late, the run has to be pulled apart completely: decombining. Every sales order line is reassessed, then everything is merged again. Most of the time that works. Sometimes a production order never makes it back into a run: it exists, it is approved, it is scheduled, but it is never manufactured. The combined order also drives the supply of semi-finished goods from other plants, so decombining ripples into logistics too.

What is an orphan production order, and why is it dangerous?

An orphan production order is one that is still tied to its sales order line, but no longer part of a combined production run. It looks fine. It is approved and scheduled. It never reaches the factory floor.

The danger is that the failure is silent. The sales order still looks healthy, so the customer assumes the product is being made, and finds out on the day delivery was expected. A custom report can spot orphans, but a report that has to catch what the process should never produce is a symptom, not a cure. What the business wants most is simple: no silent failure.

Why does a sales order cut-off that isn't enforced cause instability?

A cut-off exists so that demand is fixed and production planning can do its job: capacity locked, sequences aligned, materials committed. If changes still go through after it, the cut-off is not a rule. It is a polite request.

One quantity adjusted or one date nudged after the cut-off can shift load across lines and force recalculation when there is no time left to recover. When it is company policy never to say no, and customers know it, exceptions become the rule. Exceptions that are the rule do not protect systems. They only explain, afterwards, why one person is always needed to catch the fallout.

Why do late order changes ripple into semi-finished goods transfers?

Because in this process the individual production orders do not talk to logistics. The combined production order does. Final assembly needs semi-finished goods made in other plants, in other countries, and those movements are controlled by internal purchase orders linked to the combined run.

So when a late change forces decombining, the combined order disappears, and every production order for semi-finished goods needs reassessment as well. A change that looks trivial on the sales order reaches across plants and borders. Procurement then sees transport planned for full trucks and fixed slots suddenly change, with costs nobody recharges.

Why are lead times for cross-border stock transfers so hard to get right?

Because the calendar has more than one country in it. Work backwards from when production must start.

• If production starts on Tuesday morning, the goods must arrive on Monday at the latest. A goods receipt processing time of one day forces the receipt onto Monday, because trucks often arrive late in the evening.
• With a transit time of two days, the goods must leave on Saturday, unless nobody works at weekends; then they must leave on Friday.
• If the departure site has a public holiday on that Friday, they must leave on Thursday.

Public holidays differ between the departure and arrival countries, and spring is full of them. Seeing this is easy. Coding it into custom logic is where it gets hard.

What is the difference between procedural and object-oriented ABAP?

The book explains it with a cup of tea. Procedural ABAP asks for selection criteria (which tea, milk, sugar), follows sequential steps, and hands over the result. That is the old way of coding.

Object-oriented ABAP describes the machine instead. A coffee machine is an object. It has a state: water level, boiler temperature, whether the bin is full. You cannot see that state, because it is tucked behind the casing. That is encapsulation: it protects the internals from you, and you from the mess. You interact through methods, the buttons: tea, coffee, hot chocolate, clean the pipes.

Which is easier depends on how complex the task is. The more complex, the more object orientation pays off. And for Fiori development, object-oriented ABAP is the way SAP expects you to build.

Can you tell who wrote a piece of code?

Often, yes. Code has style, like handwriting: how logic is structured, how things are named, where the checks sit. Read enough code and you can tell who wrote it.

That makes style useful evidence. Code that reads as layered rather than designed, with the same problem solved several different ways, tells you how it was built: quickly, under pressure, and never consolidated. A consistent style across a code base is a sign that someone has been tidying; an inconsistent one is a sign that nobody has had time to.

What is vibe coding, and what is the risk for SAP custom code?

Vibe coding is the informal name for describing what you need to an AI chatbot and letting it generate the code. Little technical knowledge is required.

The risk is not that the code fails. It usually works. The risk is accumulation without consolidation. Give an AI the same prompt in a new session and you get working code that is never identical to the last version. Use that to keep patching a complex business process and you get many slightly different pieces of logic scattered over many programs. Each fix is reasonable on its own. Together they make the system harder to understand and less stable with every change.

Is AI-generated code the real problem?

No. Everyone generates code: humans with copy and paste, AI with a prompt. Generation itself is not what matters. What matters is what drives the generation.

Vibe coding is fine for the plumbing, the parts that do not change. But decisions that shift every time a customer picks up the phone should not be regenerated as new code each time. They need a place to live where they can change without touching programs, and without someone having to remember them at midnight.

Should business decisions live inside custom code?

No. Not if you ever want to explain them, change them, or let anyone own them without becoming a hostage.

Decisions buried in code are inferred, not declared. You can observe what the system does and reverse-engineer it after the fact, but you cannot point at a place and say: this is the rule we agreed. Custom tables help on the surface, but data in different tables can clash, and then more code decides which one wins. Every requirement change becomes a code change, and every code change is a risk. The book's three-line diagnosis: decisions are inferred, not declared; rules are buried inside behaviour; change is handled through reaction, not visibility.

How does BRF+ take decisions out of ABAP?

ABAP still runs the process. BRF+ makes the decisions. The core program does the plumbing: it collects the input, formats it, calls a BRF+ function, and acts on the result.

Each BRF+ function has a defined input and output: a table, a row or a single field. The rules in between turn input into output, usually with decision tables, which you can export to a spreadsheet, update and import again. When conditions change, you update a table, not a program. BRF+ generates the code behind the rules on request.

Easy as that, which does not mean easy. More on BRF+ itself: https://isard.ai/brf-plus/

How do you find the business rules hiding in custom code?

Not by reading the code. That is the wrong reflex. Extracting rules from code is archaeology: inference, treating behaviour as truth. You end up confirming what the code does, not what the business needs.

Ask the people who live with the outcomes instead. Three questions open most doors:

• What do you change all the time?
• What gets overridden?
• What do you argue about?

Stop studying consequences. Start asking expectations.

And do not ask an AI chatbot to find your business rules for you. Chatbots tend to be agreeable: ask a leading question and you get the answer you expected.

How do you interview the business about the decisions they rely on?

Talk to each department separately, and ask what they expect to happen, not what should happen. "Should" starts a policy debate. "Expect" gives people something to stand on.

Set boundaries: no new requirements, no second-guessing. Treat the system as a black box: when you put this in, what outcome do you expect back? Then ask which decision they believe is already implemented, what defines its thresholds, and what happens when it does not behave.

Listen for the gap. Business users often describe rules as if they exist in the system when they do not; workarounds fill a gap where something was never built. Prototype what people believe and you confirm an illusion.

What do sales, production and procurement usually want from late changes?

They use different words for the same gap.

• Sales wants flexibility where it matters, with context: account tier, margin, strategic accounts. Saying no costs more than saying yes. And no silent failures.
• Production wants protection of the plan: after a defined point, changes need explicit approval and a named owner, based on impact such as materials, changeover time and scrap.
• Procurement wants late changes to trigger a recalculation of cost, lead time and carrier availability, and wants those extra costs charged to whoever caused them.

None of them asks for rigidity. They all ask for visibility and ownership: keep the flexibility, but show its cost and attach a name to the decision.

What is a decision point that cannot be skipped?

It is a place in the process where flexibility is still allowed, but its cost is shown and its owner is named before the decision takes effect. Not after. Not in a report. Not in a retrospective. At the point of decision.

Today, exceptions happen silently and the consequences appear downstream: production absorbs them, procurement absorbs them, and the code carries the rest. A decision point makes every exception a decision someone takes with their eyes open. That is governance, and BRF+ is the mechanism. The argument between departments still happens, but the consequences are visible before the fact, and ownership stays with the business instead of inside the code.

Design the rules by impact, so the decision point only bites where it matters. A change outside the planning horizon, or with enough slack before goods issue, can pass with a log entry. A change that hits a production run already scheduled needs approval from a named owner. Related orders affected by the knock-on get a warning, not an error.

How do you introduce BRF+ into a running custom process safely?

Leave the old code where it is and let BRF+ act as a second opinion after it, switched on only when you decide. A workable approach:

• A switch in a system parameter table activates BRF+ per area, such as sales orders.
• Every BRF+ decision writes to the SAP application log, one entry per document touched, so everyone can read what was decided and why.
• Activate one dependency at a time: sales first, then procurement, then production.
• Pick a calm moment of the day to switch on, and watch the first documents arrive together.
• Use warnings for situations that need attention and errors for those that must stop. Where approval is needed, trigger a workflow to the business owner.
• Rehearse the exception protocol before go-live with real test cases, so that everyone knows who approves what and what happens to the orders affected.

How do you present a stability proposal to executives?

One page. Three lines. Thin means it survives the room. Do not walk through incidents; they already have the logs. Talk about where decisions live, because that is what keeps repeating.

Make the mechanism the story, not the person. Say "this is the cause" and you make a person the story; say "this is what we can do to stabilise the system" and you make the mechanism the story. Ask for one slice, a containment prototype rather than a transformation. Keep ownership with the business. And first ask what "stable" means to them, because a goal nobody has defined cannot be met.

What SAP topic sits inside Death by Email?

The intercompany end-to-end process within the EU: a sales order in one company, delivered from a plant of another company in the same group, invoiced twice. On top sits EU VAT, and in particular the EU triangulation simplification.

Its theme is that knowledge trapped in email kills the business. Two truths sit underneath: documents reflect system assumptions, not reality; and organisations rely on human assumptions nobody verifies.

Why are decisions in email threads such a risk on an SAP process?

Because an email thread is where a decision goes to be forgotten. Which VAT number to use, what a partner function should contain, when a rule applies: if those answers live only in inboxes, they leave with the person who holds them. An email thread eleven forwards deep is not documentation.

The practical habit is simple. The thread from origin to decision goes into the ticket, with a name against it. A question that lives in an inbox gets lost.

What is intercompany billing in SAP?

Intercompany billing happens when one legal entity in a group sells to a customer, but the goods are delivered from a plant that belongs to another legal entity. SAP spots that the sales organisation and the delivering plant sit under different company codes.

Two invoices follow. The selling company invoices the external customer. After that customer invoice exists, SAP adds the delivery to an internal billing list, and the delivering company invoices the selling company at internal prices. Two legal entities, one customer sale, internal cost recovery.

When does SAP decide that a sale is intercompany?

At the outbound delivery, not at the sales order. The sales order header carries the company code of the sales organisation, and each line has a delivering plant. But that plant can still change: it can come from the customer material info record, the material master or substitution rules. Partner data or pricing may hint at intercompany, but hints are not decisions.

When the outbound delivery is created, the delivering plant is fixed. SAP then compares the company code of the sales organisation with that of the delivering plant, and if they differ, the delivery becomes relevant for intercompany billing. The order is the plan written in pencil. The delivery is the same plan written in ink. Only the ink counts.

Which invoice comes first in intercompany billing?

In standard SAP, the customer invoice comes first and the intercompany invoice second. The lock is the billing index: posting the customer invoice creates the billing index entry that puts the delivery on the intercompany billing due list. Until then, the delivery does not appear in collective or background billing.

The pricing is independent: PR00 prices the customer invoice, IV01 the internal charge, and one does not feed the other. Manual billing in VF01 with the intercompany billing type can bypass the sequence. Reversing it for collective or background billing needs a modification, described in SAP Note 38501, which also explains report RVV05IVB to create index entries for existing deliveries.

What happens with intercompany billing when goods are free for the customer?

Free for the customer does not mean free between companies. The delivering company still gives away stock and carries the cost, and that normally needs settling.

There are two safe designs:

• Allow a customer invoice with a value of zero. The standard sequence stays intact and the intercompany invoice follows at an agreed internal price.
• Skip the customer invoice but keep the delivery relevant for intercompany billing, with a fixed transfer price.

Avoid the third path, where the free item has no billing relevance at all. Then no intercompany invoice can be created and the delivering company quietly carries the loss. Choose that only as a deliberate decision to absorb the cost.

What is triangular billing, or triangulation?

It is intercompany billing in a three-party chain. Selling company A owns the customer relationship. Delivering company B owns the plant. Customer C receives the goods directly from B. A invoices C. B invoices A. Three parties, two invoices, one physical movement.

What makes it triangular is the split between commercial responsibility and physical delivery: A remains contractually responsible to the customer while B fulfils the shipment. The internal settlement between A and B works exactly as in any intercompany sale. In the book's framing, every intercompany sale from a sales order with direct delivery to the customer creates this triangle; the delivery that triggers intercompany billing is the same delivery that creates the triangle.

What is the difference between a linear and a triangular intercompany flow?

It depends on whether the goods pass through the selling company.

• Linear (intercompany indirect delivery): B supplies A with a stock transport order, A receives the goods into its own warehouse, then ships to C as a normal sale. Physical flow B to A to C; commercial flow B to A to C. Aligned. If both movements happen at once, the site is probably cross-docking, but the structure is still linear.
• Triangular (intercompany direct delivery): A sells to C, B ships straight to C, A never touches the goods. Physical flow B to C; commercial flow B to A to C. Not aligned.

In the book's framing, the linear structure starts from a purchase order and the triangular one from a sales order. Only the triangular structure can bring the EU triangulation simplification into play.

Does every triangular intercompany flow use the EU triangulation simplification?

No. The triangle is a logistics and SAP structure: it exists whenever the selling company and the delivering plant sit in different company codes and the goods go straight to the customer. VAT law does not create the triangle. It decides how the triangle is treated when goods cross borders.

The EU triangulation simplification only becomes relevant when the parties sit in different EU member states and its legal conditions are met. The triangle never changes. What changes is the consequence of getting it wrong.

Why would the selling company need a VAT registration in the customer's country?

Start with the normal two-party case: the seller zero-rates the supply in the country of departure, and the buyer accounts for acquisition VAT in the country of arrival. That works cleanly for two parties. Three parties are where it gets awkward.

Take seller A in France, supplier B in Germany and customer C in Italy, each VAT-registered only at home. The goods go from Germany straight to Italy. A invoices C; B invoices A. Ownership changes twice, so there are two sales: B to A, then A to C.

The goods arrive in Italy, so someone must account for Italian VAT on that arrival. Because A is the contractual seller and the goods arrive in Italy, A becomes liable, and would need an Italian VAT registration.

Note what the single market did and did not do. It removed customs borders and duties between member states. It did not remove VAT, which is still a national tax. Cross-border VAT consequences remain, even with no customs officer at the border.

What does the EU triangulation simplification do?

It removes the need for the intermediary, seller company A, to register for VAT in the country where the goods arrive. Provided the legal conditions are met, the obligation to account for VAT on arrival shifts from A to the final customer C.

The commercial structure stays the same. The physical movement stays the same. Only the reporting obligation moves. It is a targeted fix for a VAT registration anomaly that arises only in a three-party direct delivery chain. It is not about free movement of goods, and it does not apply automatically just because three parties are involved. Besides the transport allocation, the simplification has further legal conditions, for example on what the intermediary's invoice must state and how the intermediary reports the sale. Those belong with a tax adviser.

Why do both invoices show zero VAT under triangulation?

Because the tax has not disappeared; it is declared somewhere else. Supplier B in Germany invoices seller A in France without German VAT. A invoices customer C in Italy without French VAT and references the triangulation simplification. On paper, no tax is charged anywhere.

Italian VAT is still legally due on arrival. C accounts for it through the reverse charge mechanism: it declares the VAT as output tax in its Italian return and, subject to deduction rights, the same amount as input tax. The net payment is usually zero, but the VAT is reported.

This is the dangerous part in practice. Zero-VAT invoices look like confirmation that the setup works. They are appearance, not proof.

What is the hidden precondition of the triangulation simplification?

There are two sales in the chain but only one cross-border transport, and under EU VAT rules only one of the two sales can be the intra-Community supply. Which sale carries the transport decides the VAT treatment of the whole chain.

For the simplification to apply in this scenario, the transport must belong to the sale from supplier B to seller A. Then B to A is the zero-rated intra-Community supply from Germany, A makes an intra-Community acquisition, and A to customer C becomes a supply in Italy, which the simplification shifts to C.

That allocation is not optional and not automatic. If the transport belongs to A to C instead, the simplification fails and A needs an Italian VAT registration, whatever the invoices show.

Who arranged the transport, and why does it matter?

Because VAT law looks at who arranged the transport to decide which sale carries it. Chain transactions are governed by Article 36a of the EU VAT Directive (2006/112/EC).

In outline, as researched for the book:

• When the delivering company, B, arranges the transport, it belongs to the supply from B to seller A. That supports triangulation.
• When the intermediary, A, arranges the transport, it is presumed to belong to the supply to A: B to A. That normally supports triangulation.
• The exception: if A gives B a VAT number from the dispatch country (here a German one), the transport shifts to A to customer C, and the simplification fails. In a triangulation, A must use a VAT number from another member state.
• If the customer arranges the transport, A may not qualify as the party dispatching it, which can invalidate the simplification.

"Who arranged the transport?" is the right question, but on its own it is incomplete. An auditor will also ask how you prove it.

Does SAP store which sale carries the transport?

No. SAP has no field for transport allocation. It has to be reconstructed from consistent evidence across the document chain.

Standard SAP VAT determination looks at the plant country, the ship-to country, the customer tax classification and the material tax classification. That works for two-party transactions but cannot reconstruct the legal structure of a chain. The system applies tax logic based on assumptions built into the configuration, so invoices can look perfectly correct while the legal structure is not. Tax engines such as Vertex perform chain flow mapping for this reason. In short: SAP documents provide evidence; legal analysis happens elsewhere.

Which VAT numbers belong on which document in a triangulation?

With seller A in France, supplier B in Germany and customer C in Italy, the pattern that keeps the transport attached to B to A is:

• Sales order: A's French VAT number and C's Italian VAT number. It defines the commercial transaction.
• Delivery: usually no VAT numbers. It is the logistics confirmation.
• Intercompany invoice: B's German VAT number and A's French VAT number. It creates the intra-Community supply from Germany to France.
• Customer invoice: A's French VAT number and C's Italian VAT number, as the sale under the triangulation simplification.

Result: B to A is the intra-Community supply, and A to C is a supply in Italy under reverse charge. If A uses a German VAT number instead, the transport shifts to A to C and the simplification fails.

Can I rely on the Incoterms on the intercompany invoice?

No, not as evidence of the supplier B to seller A transport arrangement. In standard SAP, Incoterms start in the sales order and are copied through the delivery into both billing documents. SAP Note 16794 explains that intercompany billing copies the Incoterms from the delivery, not from the internal customer master. SAP KBA 1505425 confirms it, and KBA 3337058 says the same for S/4HANA Cloud, where they are not redetermined at billing.

So the intercompany invoice always shows the end customer's Incoterms, unless you add a VOFM data transfer routine. Identical Incoterms on both invoices prove that copy control worked. They prove nothing about who arranged the transport.

What evidence shows who arranged the transport in SAP?

The research for the book Death by Email ranks the evidence like this:

1. The VAT number the intermediary communicated: the legal presumption under Article 36a.
2. Logistics execution: delivering plant and goods issue, proof the shipment happened.
3. Forwarding agent, carrier, broker or transportation planner partner functions: who arranged it.
4. Incoterms: commercial intent, but unreliable in SAP because of copy behaviour.
5. Freight pricing: supporting evidence only.
6. Tax codes: the output of tax determination. Useful as a classification flag, not as proof that the legal precondition was met.

The delivery holds the strongest logistics evidence: delivering plant, shipping point, goods issue and the partner functions. Note that the forwarding agent partner function is often optional and left empty. An empty field is missing evidence, not a field someone checked and found empty.

Why does the triangulation simplification fail in practice?

The common failure scenarios:

• The intermediary uses the wrong VAT number, typically one from the dispatch country.
• The forwarding agent, carrier, broker or transportation planner in SAP does not match reality, or is missing.
• Copy control puts the customer's Incoterms on the intercompany invoice, and people read them as evidence.
• The data hints that the customer collected the goods.

A common pattern behind them: zero-VAT invoices are read as proof, and nobody verifies the precondition. Each document can be internally consistent while the chain as a whole is legally invalid.

In the book Death by Email, the main issue is that the intra-Community supply is not clarified in the sales documents.

How did Brexit change intercompany flows with Great Britain?

It did more than break triangulation. The EU triangulation simplification needs three VAT-registered parties in three EU member states, so a company with only a GB VAT number cannot take part. But the bigger impact is the loss of intra-Community supply treatment itself.

Before Brexit, moving goods between a UK plant and a German plant had no customs formalities, although VAT reporting still applied. Now it crosses a customs border: an export declaration leaving the UK, an import declaration arriving in Germany, import VAT at the German border, possibly customs duties depending on origin, a named exporter and importer of record, and a declared customs value that may or may not match the intercompany transfer price.

What is an intercompany stock transport order?

It is how one legal entity in a group orders stock from another when no external customer is involved: a plant in one company code orders from a plant in another with a stock transport order (STO). Because ownership changes between legal entities, the transfer must be settled financially.

How it is settled depends on configuration: the STO document type, one-step or two-step transfer, and the valuation and movement types. If the STO uses delivery and billing, SAP creates an intercompany invoice through the same billing engine as customer sales. If not, the transfer is settled with automatic accounting postings, using clearing accounts and rules driven by the goods movement.

What master data does an intercompany stock transfer need?

Both sides of the relationship must exist in master data. The receiving plant must exist as a customer in the supplying company code, because the outbound delivery needs a delivery address, shipping data and a billing partner. The supplying plant acts as a vendor to the receiving company.

On the STO itself, the header is the receiving side: receiving plant, linked to a purchasing organisation, linked to a company code. Each line carries a supplying plant in another company code. Configuration then connects it all: shipping data for plants, STO delivery type, shipping point determination and intercompany billing. It is a cross-module process: MM provides the purchase order, valuation and goods movements; SD provides the delivery, shipping and the intercompany invoice. Without these links you get a technical stock movement, not a governed transfer of ownership.