DEV Community: 전현재

Subcontracting vs external processing in SAP — same shop floor, different books

전현재 — Sat, 15 Aug 2026 09:31:53 +0000

Both arrangements mean the same thing on the shop floor: an outside vendor performs a step for you. The difference lives in the account determination, and you can identify which one a company actually implemented by reading the keys in the material document.

Here are the three fingerprints, from a sandbox where I ran all of them on the same product.

In-house production

Consumption posts with VBR / AUF. The production order is the cost collector: components go in, the finished material comes out, and the order carries the difference until settlement.

Nothing surprising — this is the baseline the other two get compared against.

Subcontracting

You send components to the vendor (541 movement) and receive back a different material number.

Consumption of the provided components posts with VBO
The subcontracting fee lands via BSV

The fee gets its own account (9050 in my build) because it is a purchased service embedded in a material, not internal labour. From the system's point of view the vendor made the part; you supplied ingredients.

External processing

The operation stays on your production order. The order remains the cost collector (VBR / AUF), and the external step arrives as an FRL posting against a separate account (9070). The material never leaves your books as a different number — it is still your part, one of whose operations happened elsewhere.

The practical consequence for product costing

This is where the choice stops being academic.

Subcontracting appears in the standard cost estimate as a purchased price. The itemization gives you one line and no visibility into what that line is made of. If your cost estimate suddenly lost its material breakdown for one component, this is usually why — and it means your variance analysis for that part is blind.

External processing keeps the BOM explosion intact. You still see the components, and the external operation shows up as one more cost element alongside labour and machine time.

Neither is wrong. But if someone asks "why can't I see what's inside this part's cost," the answer is often that a procurement decision, made years ago for entirely non-accounting reasons, collapsed the structure.

How to tell which one you are looking at

Open the material document and read the account determination key. VBO plus BSV means subcontracting. VBR/AUF plus FRL means external processing. VBR/AUF alone means you made it yourself.

From a dumpling factory built from scratch in S/4HANA to document a full month end-to-end. There is a free 16-page sample of the write-up.

GR/IR explained with real documents — why buying something has zero P&L impact

전현재 — Sat, 15 Aug 2026 09:23:56 +0000

A confusion I keep running into: people assume a purchase order does something to the books. It does not. I ran a full procure-to-pay cycle in an S/4HANA sandbox and pulled every document, so here is the actual accounting story with nothing hand-waved.

The purchase requisition and the purchase order post nothing

No FI document. No CO document. They are planning objects — a statement of intent and a commitment to a vendor. If you go looking for their financial effect you will not find one, because there isn't one.

This is worth internalising, because it means the moment money "happens" is later than most people assume.

Goods receipt is the first real posting

Dr  1050 Raw materials      5,000
Cr  9010 GR/IR clearing     5,000

The warehouse now has stock, and the books now carry a liability-shaped placeholder: we have received goods we have not been billed for.

Invoice receipt closes it

Dr  9010 GR/IR clearing     5,000
Cr  2100 Vendor (AP)        5,000

The placeholder is replaced by a real payable.

GR/IR is the referee

The GR/IR account exists to hold the disagreement between two departments who measure different things. The warehouse says "we received goods worth X." Accounting says "we were billed for Y."

When GR/IR does not clear to zero, one of the two is wrong, and the account tells you which direction. That is the three-way match — purchase order, goods receipt, invoice — expressed as a single balance you can look at.

The consequence people miss

The entire purchasing cycle has zero P&L impact.

Nothing hits expense. Inventory goes up, a liability goes up, the balance sheet gets longer, and the income statement does not move. Cost appears later — when the material is consumed into a production order, or when the finished goods are sold.

If your P&L moves when you buy things, something is misconfigured. The usual culprit is an account assignment category sending the receipt straight to a cost center instead of to stock.

Why this matters beyond bookkeeping

Once you see procurement as "balance sheet only," a lot of downstream confusion resolves itself. The month where you buy heavily is not automatically a bad month. The cost shows up when the value is actually consumed, which is exactly what you want if you are trying to read a margin.

This is from a dumpling factory I built from scratch in S/4HANA to document a full month end-to-end, every document number verified. There is a free 16-page sample of the write-up.

A 36% margin became 6% at month-end, and nothing was posted wrong

전현재 — Sat, 15 Aug 2026 09:20:55 +0000

I built a small manufacturing company end-to-end inside an SAP S/4HANA sandbox — one plant, one product, one month — specifically to watch what the month-end close does to a margin that looks healthy at billing time. Every number below comes from an actual document in that system.

At billing, the month looked good


Revenue	20,000
COGS at standard	12,800
Margin	7,200 = 36%

Three days later, after the close, the same month landed at 1,200 = 6%.

Nothing was posted incorrectly. Three gates took the 30 points, in this order.

Gate 1 — Cost center revaluation (KSS1 / KSII)

The planned price for the labour activity type was derived the usual way: planned cost divided by planned activity quantity. Production orders consumed hours at that planned rate all month.

Then the actuals arrived. Depreciation posted 9,000 against a plan of 3,000. Activity quantity did not move. So the actual activity rate came out at roughly three times the planned rate, and every hour any order had already consumed became retroactively more expensive.

This is the part that surprises people: the damage was decided weeks earlier, in a transaction nobody files under "costing decisions" — planning the activity price.

Gate 2 — Order variance (KKS1 / CO88)

With the revalued rate applied (CON2), the production orders no longer settled clean. The difference split across variance categories and settled to variance accounts — not into inventory.

That distinction matters. If it went to inventory, it would sit on the balance sheet until the goods were sold. It doesn't. It is parked, waiting for the next step.

Gate 3 — Actual costing (CKMLCP)

This is the step people forget, and it is where the margin actually dies.

The actual costing run rolls the variance into the material's periodic unit price, and then moves the portion belonging to what was already sold into COGS. Before this run, the P&L still looked fine. After it, the 6,000 that had been sitting in variance found its way onto the income statement.

What I took from it

A margin at billing time is a standard margin. It is a statement about the cost estimate, not about the month.
The three gates are a pipeline: revalue the rate, recompute the order, move the difference to the sold goods. Skip the third and the books look better than they are.
A 3x error on planned depreciation is a 3x error on every labour hour the plant books, and it is invisible for four weeks.

If you own product costing: how do you catch a drifting activity rate before the close, rather than explaining it afterwards? I would genuinely like to hear the practical answers.

This is from a dumpling factory I built from scratch in S/4HANA to document a full month end-to-end. There is a free 16-page sample of the write-up if you want to see the format.