Global supply chain

A global supply chain that actually posts

One finished product. Components bought in the US, first assembly by a vendor in China, completion at an affiliated plant in India, sale back out of the US. Here is what actually posts in S/4HANA, and where the design usually goes wrong.

CR Srini · Independent SAP S/4HANA Finance Architect

Most supply chain designs I review are correct on the slide and wrong in the ledger. The flow diagram shows material moving between three countries, everyone nods, and the design goes to build. Six months later someone in Finance asks why work in process in the US plant does not reconcile, and the answer takes three weeks to find.

So let me walk through a real one, anonymized. Two manufacturing plants and one external vendor:

What the flow looks like

US01 receives a customer order for a finished assembly and creates a production order against it. The components come from one purchase order placed by US01, drop-shipped from the supplier directly to both subcontractors. Nothing physically touches the US plant except a kit that US01 assembles in house first.

The China vendor performs the first operation and ships the partly built product on to India. IN01 completes it. The finished product ships to the customer, and IN01 bills US01 intercompany for its work.

Straightforward on a page. The design question is what all of that means in the universal journal.

The trap: inventing a sub-assembly

The instinct is to model this as material flow. The China vendor builds a sub-assembly, so give it a part number, receive it into US01, issue it onward to India. That is how most people draw it and it is wrong here.

There is no sub-assembly part number in US01, because US01 never takes possession and never needs to value one. The China vendor assembles the finished product itself, incomplete, and India completes it. From US01's point of view both parties are routing operations that invoice a manufacturing service. Nothing more.

Get this wrong and you create a phantom part that has to be costed, planned, counted and reconciled, for no business reason. You also invent goods issues that the physical process does not support, which is exactly the sort of thing that shows up as an unexplained work in process balance after go-live.

What IN01 does internally is a separate question. India needs its own local part to issue against its own production order, and that is fine. It is an India part on an India bill of material. It does not belong on the US01 structure, and the two do not need to reconcile item for item.

What actually posts

Strip the story back to documents and the picture gets simple:

• One component purchase order in US01, covering the parts for both subcontract operations.
• One goods issue to the subcontractors when those components are consumed. That is the only material movement of components in the flow. Everything else is service.
• Two service receipts. One when the China vendor's operation is confirmed, one when India's is. Work in process in US01 rises at each.
• One intercompany billing document from IN01 to US01, and the matching payable in US01.
• One customer invoice from US01, with cost of goods sold at standard and the variance posted separately.

Under event-based production costing the work in process and variance postings happen at confirmation rather than at period end, which is a real improvement. It also means a design error is visible in the ledger the same day instead of at month end. That is a benefit if someone is looking, and a liability if nobody is.

The intercompany leg is where the money hides

Two design decisions on the India leg matter more than everything else on the diagram.

First, the transfer price. IN01 is a separate legal entity performing a service for US01. That is an arm's length transaction and it needs a markup. I regularly see this configured at zero markup, priced at cost, because it was set up as an inventory transfer rather than a sale. The postings balance, so nothing looks broken. What you have actually built is a transfer pricing exposure, and the India entity showing no margin on work it genuinely performed.

Second, the cost component structure. The China service charge and the India service charge have to land in separate cost components with their own general ledger accounts. Not because costing needs the detail, but because group reporting does. When you consolidate, you have to eliminate the intercompany profit in the India charge and leave the China charge alone. If both are sitting in one external processing bucket, nobody can separate them without a spreadsheet, and the elimination becomes a manual journal that somebody re-derives every quarter.

Decide both before the first productive posting. Cost component structures are not something you change comfortably once there is history behind them.

Three things to fix before go-live

1. Set the intercompany price policy explicitly, in writing, with tax. Not as a configuration afterthought. If your affiliated plant is billing at cost, that is a decision somebody has to own, not a default nobody noticed.
2. Split the variance categories. A single figure telling you the order ran over standard is not actionable. Input price, input quantity, resource usage and lot size each point at a different owner. Configure the split before you have a quarter of unexplained variance to explain.
3. Name who reviews variances daily. Event-based costing surfaces problems immediately. That only helps if the report has an owner. In most of the programs I see, this is unassigned at go-live and stays unassigned until the first bad close.

The wider point

None of this is exotic configuration. Subcontracting, intercompany billing and event-based costing are all standard, and the system handles this flow well once it is modeled honestly.

The failures come from modeling the process as somebody wishes it worked rather than as it physically runs. A vendor who performs an operation is a service. A vendor who delivers a part is a material. Getting that one distinction right at design time saves a great deal of reconciliation later, and it is the sort of thing that is very cheap to fix in a workshop and very expensive to fix after go-live.

If you are designing a flow like this, the test is simple. Walk one order end to end and write down every document that will exist. If your list has documents in it that nobody can point to a physical event for, the model is wrong.