Predictive Accounting in SAP S/4HANA Cloud: A Worked Week at One Company

A CFO closes the books for May at 6 p.m. on the fifth working day of June. At 6:01, sales emails her about an enterprise deal that signed yesterday. At 6:02, procurement tells her about a six-figure equipment commitment the head of IT raised on the 28th. At 6:03 the services team mentions a new managed-services contract that goes live July 1 — yes, this changes the half-year revenue trajectory.

None of those three events have posted a single journal entry. By the rule book, the May close is correct. By any useful definition, the May picture is already wrong.

Predictive accounting in SAP S/4HANA Cloud is the answer to that gap. It uses a special prediction ledger (0E) to post predicted journal entries the moment a sales order is saved, a service contract is released, or a purchase order is raised — before any of those events trigger a real GAAP posting. As reality lands in the regular underlying ledger (0L), the predictions in 0E reverse themselves. Your reporting view always reflects what's actually booked plus what's about to be.

This article walks the whole concept through a single business week at a fictional company. Different style on purpose: less narrative, more here are the journal entries, here is the timeline, here is exactly what your screen shows on Tuesday afternoon.

Here's the whole concept in one frame. The article expands each section underneath.

A few terms first — for finance readers new to S/4HANA

Most of this article makes sense only if these words mean the same thing to you and to the system. One sentence each:

• Underlying ledger (0L) — the leading ledger in S/4HANA. Holds the actual GAAP journal entries. What's on the statutory P&L and balance sheet.
• Extension ledger — a ledger that adds to a base ledger. Reads together with the base; doesn't replace it. Used here for predictions.
• Prediction ledger (0E) — the specific extension ledger used by predictive accounting. Stores predicted journal entries.
• Scope item — SAP Cloud's named bundle of activated functionality. 2FD, 4V7, 2I3 are the three scope items for predictive accounting.
• Goods issue (GI) — the inventory movement when finished goods physically leave the warehouse for a customer. Triggers the COGS posting.
• COGS — Cost of Goods Sold — the manufacturing cost of the units that were sold. Posted at goods issue, not at sales-order entry.
• Goods receipt (GR) — the inventory movement when purchased materials arrive. Posts to Inventory and GR/IR clearing.
• GR/IR clearing — a temporary balance-sheet account that bridges goods receipt and supplier invoice. Cleared when both have posted.
• Encumbrance / commitment — funds reserved against a budget for a purchase that hasn't yet posted as an expense.
• BDR — Billing Document Request — the document that triggers an invoice for a service contract. Created in batch via a scheduling app.
• WBS element — a node in a project's Work Breakdown Structure, used as an account-assignment object.
• Event-based revenue recognition — S/4HANA's IFRS-15 / ASC-606 engine that posts revenue at each business event (rather than only at period-end).

Meet PolarLine Refrigeration

To keep this concrete, every example below uses the same imaginary company.

PolarLine Refrigeration GmbH is a mid-sized manufacturer of commercial refrigeration units in southern Germany. They build supermarket display freezers and walk-in cold-rooms in a single plant. They also sell multi-year maintenance contracts for their installed base, and they procure raw materials (steel sheet, compressor units, refrigerant, electronic boards) through a normal corporate purchasing process. All three predictive accounting scopes apply to them:

• Sales orders for finished freezer units → scope item 2FD
• Service contracts for maintenance on the installed base → scope item 4V7
• Purchase orders for production raw materials → scope item 2I3

The week we'll follow runs Monday to Friday of a normal June. Five working days. Three scopes touched.

What predictive accounting is — in one paragraph

Predictive accounting in S/4HANA Cloud takes data from your non-finance areas — sales, services, purchasing, Concur, integrated products — and writes predicted journal entries into a special extension ledger called the prediction ledger (0E). The prediction ledger is structured exactly like your underlying ledger (0L), so it can be read by all the same analytical apps and reports. The actuals stay in 0L. The predictions sit in 0E. Reporting tools that look at "everything" see them combined; tools that need only GAAP-actuals can filter 0L only.

That single architectural decision — predictions live in a parallel ledger that knows how to subtract itself when reality arrives — is what makes the whole thing work without polluting your books.

Three scopes, three things it watches

You don't activate "predictive accounting" once. You activate one or more scope items, each of which covers a specific business process.

The trade-off is honest:

• 2FD (sales) — best ROI for any sales-led business. Real-time revenue forecast that includes every signed but-not-yet-shipped order.
• 4V7 (service contracts) — best for subscription and managed-services businesses where the headline metric is annualised recurring revenue. The contract release itself triggers a full-life-cycle revenue prediction.
• 2I3 (commitments) — best for project-driven and public-sector organisations where over-committing a cost centre is the daily hazard. PR/PO raises encumber the budget immediately.

You can mix and match. PolarLine activates all three.

The week, day by day

Here's the calendar view. The prediction ledger (top track) rises Monday–Wednesday as business events happen, then partially reverses Thursday–Friday as actuals post.

Let me walk through each day with the actual journal entries.

Monday — a sales order writes its own forecast

PolarLine's sales team closes the deal with NordKette Markets (a regional supermarket chain) at 11:30 a.m. The order SO-101 is for 10 display freezers at €5,000 each, total €50,000. Standard cost from the routing+BOM is €3,000 per unit, so the COGS prediction is €30,000.

Sales order saved. Nothing posts to the underlying ledger 0L — sales orders alone never have. But scope 2FD is active, so the prediction ledger 0E immediately gets four predicted lines:

The document numbers carry a prefix (typically PA-…) so anyone looking at the GL view can tell predictions from actuals at a glance.

At 11:31 a.m. the live revenue forecast for June is €50,000 higher than it was at 11:29 a.m. — without anybody having posted anything to GAAP. The CFO's Incoming Sales Orders — Predictive Accounting app shows SO-101 as Active prediction, status not yet obsolete.

Tuesday — a purchase order encumbers the budget

The production planner raises PO PO-505 for 20 compressor units at €400 each, total €8,000. The PO is account-assigned to production cost centre PROD-COMP. These compressors are the long-lead component on every PolarLine freezer — the planner orders them on a steady weekly rhythm.

PO created. Again, nothing posts to 0L. But scope 2I3 is active, so the prediction ledger captures the commitment:

Just one line — commitments are statistical, not financial. If budget availability control is also configured, this is the moment that an over-budget PO would be blocked before it even saves. The production cost-centre owner opening their budget view sees the €8,000 already eating into their remaining authorisation, not waiting for a goods receipt three weeks from now.

Wednesday — a service contract predicts a whole year of revenue

PolarLine's services group releases maintenance contract SC-A1 with Edelweiss Hotels: planned preventive maintenance on 30 installed walk-in cold-rooms across 12 properties. €12,000 per quarter, 12-month term starting July 1. Total contract value €48,000.

The contract release itself doesn't book anything in 0L — event-based revenue recognition will eventually do that quarter by quarter. But scope 4V7 fires immediately and writes the full year's worth of predictions to 0E:

• Predicted accrued revenue for the period between today and the first invoice
• Predicted deferred revenue for the period after the first invoice but before service is performed
• Predicted billing entries for each scheduled BDR (billing document request) — four of them, one per quarter

The Schedule Billing Document Request Creation app is what makes this complete. If BDRs are scheduled to be created daily and the horizon is left empty, the prediction ledger ends up with the whole contract life-cycle as predicted invoices the moment the contract is released.

PolarLine's CFO can now open the FY revenue forecast on Wednesday afternoon and see the €48,000 of SC-A1 already in the H2 view — three quarters before the first real invoice posts.

Thursday — reality arrives for the PO

The compressors are delivered to PolarLine's goods-in dock. A valuated goods receipt posts in 0L:

Simultaneously — by predictive accounting itself, not by any human — the original commitment in 0E reverses. A new prediction line posts with the opposite sign:

Cost centre PROD-COMP's encumbrance is now back to zero in 0E, but its actual expense (well, capitalised inventory cost) is €8,000 in 0L. Reporting that combines both ledgers shows €8,000 spent and €0 encumbered — exactly correct.

Friday — the sales order ships

PolarLine ships the 10 display freezers to NordKette. The goods issue posts to 0L:

And predictive accounting reverses the COGS half of Monday's prediction in 0E:

The revenue and receivables halves are still in the prediction ledger because the billing document hasn't posted yet — it's still 'expected'. When billing posts (let's say Monday of next week), the remaining €50,000 prediction reverses in 0E and a real entry posts in 0L. End of cycle.

By the end of this Friday, PolarLine's combined reporting view shows:

• € 8,000 actual inventory addition (PROD-COMP cost centre) in 0L
• € 30,000 actual COGS in 0L
• € 50,000 predicted receivable + revenue still in 0E (sales billing pending)
• € 48,000 predicted accrued/deferred revenue in 0E (service contract running)

All correct. All visible. All drillable from a single P&L.

The journal-entry pattern — once it clicks, it clicks

Every prediction lives the same four moments. Always.

1. Business event happens — sales order saved, PO created, service contract released.
2. 0E gets a predicted journal entry, prefixed so it's recognisable.
3. Actual posts to 0L — goods issue, billing document, valuated goods receipt, or a revenue-recognition run.
4. 0E reverses the matching prediction — a new prediction with the opposite sign cancels the original.

If the prediction was wrong (say the predicted COGS was €30,000 but the actual is €31,200), the reversal still cancels the original €30,000 and the actual €31,200 stands. The reporting view ends up correct either way.

Setup — what your basis admin actually does

All three scopes are non-standard and non-default. Activation goes through SAP for Me.

The single rule worth highlighting in red: predictions are only generated for documents created after activation. Sales orders, POs and contracts that already existed when scope items were turned on are silently excluded. There is no retro-fit. Plan the activation date with a clean cut-off month-boundary.

Five things finance teams actually gain

After PolarLine's CFO has lived with predictive accounting for a quarter, here's what changes:

• The "surprise call" goes away. Sales no longer needs to email the CFO about big orders that closed but haven't shipped — they're already in the forecast view.
• Period-end forecasting becomes a daily report, not a monthly project. Open sales orders, open service contracts and open POs all already appear in the P&L view.
• Budget control works at the moment of intent. Procurement raises a PO; the cost centre is encumbered; over-budget moves are blocked before they save, not after the goods receipt three weeks later.
• Revenue recognition timing becomes visible. Service-contract accruals and deferrals appear in the prediction ledger for the whole contract life-cycle, not just the period that closing happens to process.
• Audit drill is preserved. Click a predicted figure in any analytic — drill straight to the sales order, PO or service contract document that drives it. The universal journal architecture means actual and predicted live in the same drill path.

What you don't get is changed GAAP. The underlying ledger is untouched. Predictions never appear on statutory reports unless someone explicitly chooses to display them.

A few caveats worth knowing

Predictive accounting is well-shaped but it has edges.

• Split-valuated materials. The predicted goods-issue cost uses the parent segment (average value across valuation types). The actual GI might use a specific valuation type with a different value. The reversal still cancels exactly; only the predicted-vs-actual delta differs.
• Sales-order changes after creation. A material or quantity change after the prediction was written triggers a new predictive journal entry that updates the original — but the original is reversed first. The audit trail shows the chain cleanly; the reporting view stays in sync.
• Commitments on plant-maintenance orders. Supported, but the account assignment category must be one of the predictive-friendly ones — check the SAP Help list for your release.
• Currencies. Predictions are stored in all parallel currencies of the underlying ledger. No special configuration needed; consolidation already works.
• Period locks. If the predicted posting date falls in a locked period, the system shifts to the next open period — the prediction is preserved but the bucket it lands in may surprise you. Worth verifying around year-end.

FAQ

Is predictive accounting a separate license? No — it's a standard capability of SAP S/4HANA Cloud, gated only by activating the scope items.

Can I have it in S/4HANA on-premise? Predictive accounting was developed in the cloud first. On-premise availability varies by release — verify with SAP for your specific version. The architectural concept (prediction ledger 0E + scope-driven write-and-reverse) is the same wherever it ships.

What if I activate 2FD then turn it off? Existing predictions in 0E remain as historical posts but no new ones are written. To completely "clean" the prediction ledger you'd need to reverse the open ones manually — generally not recommended; just leave them and they'll eventually reverse themselves as their actuals land.

Does it slow down sales-order entry? The predictive postings happen synchronously and are very fast (single-digit milliseconds in tested environments). Users entering sales orders don't perceive a difference.

Is the prediction ledger included in consolidation? No — 0E is an extension ledger and is excluded from statutory consolidation by default. Group reporting tools that can show predictions (e.g. management consolidation views) treat it as an opt-in source.

What about IFRS 15 / ASC 606 contract liabilities? Event-based revenue recognition already handles these — the predictive integration just gives you visibility earlier. The recognition pattern doesn't change; the timing of when you can see it does.

Key takeaways

• Two ledgers, one truth. The underlying ledger (0L) holds actuals. The prediction ledger (0E) holds predictions. Reporting combines them; statutory reports use 0L only.
• Three scopes, opt-in. 2FD covers sales orders, 4V7 covers service contracts, 2I3 covers commitments. Mix and match.
• The pattern is always: event → prediction → actual → reversal. A prediction lives in 0E exactly until its matching actual posts in 0L, then it reverses itself.
• Activation is a clean cut-off. Documents created after you activate get predictions; existing documents don't. Plan the activation date.
• The CFO gain isn't lower close effort — it's lower surprise. The May picture you carry around mid-month is the same picture the books eventually report, plus a small known reconciliation. The "wait until close" lag is gone.

Predictive accounting doesn't change what you book. It changes when you see what you're about to book.