How to Accelerate the Month-End Close in SAP S/4HANA
Where the days actually go, which S/4HANA capabilities remove them, and how to change the process so the gain survives the next quarter.
Client dossier · September 2026 · CFOs, Controllers, Finance IT, PMs
Download Full Dossier (PDF, EN)Most finance teams that moved to S/4HANA still close the way they closed in ECC. The platform removed several reasons the close used to be slow — reconciliation between modules, batch aggregation, waiting for extracts — but the calendar, the manual journals and the intercompany chase came along with the migration. Accelerating the close is therefore rarely a technical project: it is a sequencing problem with technical enablers.
One journal
The Universal Journal removes whole categories of reconciliation work from the close
Day −5
A fast close starts before period end, not on the first working day
Intercompany
Usually the single largest source of delay — and the most automatable
3 levers
Data model · orchestration · continuous accounting. Pulling only one rarely moves the date
Key takeaway for finance leaders: before buying anything or configuring anything, measure the close at task level for two cycles: who did what, when it started, when it finished and what it was waiting for. In almost every landscape, a handful of tasks — intercompany differences, GR/IR, manual journals awaiting approval, one late subsidiary — account for most of the elapsed time. That measurement is what turns “close faster” into a plan.
If a task exists to reconcile two sets of numbers that S/4HANA now keeps in one place, it should be deleted, not automated.
Accruals, allocations, intercompany matching and bank reconciliation can all run during the month instead of after it.
Review what breaks a rule, not everything. Materiality thresholds and validations turn review into a short list.
Where the Days Actually Go
The close is a chain of dependencies, and its length is set by the longest path — not by how hard everyone works. Two or three tasks usually hold the rest hostage.
Pre-close: cut-offs, recurring entries, early accruals, master data checks
Sub-ledgers close: AP, AR, banks, assets, inventory
Accruals, allocations, FX, intercompany matching and elimination
Review, adjustments, local statutory checks
Consolidation, group pack, management reporting
The usual bottlenecks, and what actually causes them
Looks like: Two entities disagree, e-mails fly, an adjustment is posted late
Usual cause: No shared matching rules or tolerance, and no cut-off agreed between entities
Looks like: A long list of open items investigated every month
Usual cause: Process defects upstream: receipts without invoices, price differences, unreturned goods
Looks like: Hundreds of entries, each needing preparation and approval
Usual cause: Recurring entries never automated; thresholds never agreed; approval queues without deadlines
Looks like: Spreadsheets collected from the business late in the cycle
Usual cause: Accruals treated as an estimate exercise instead of a repeatable posting rule
Looks like: Material ledger and settlement runs sequenced at the end
Usual cause: Errors surface only at run time because nothing checks them during the month
Looks like: The group waits for a single subsidiary every month
Usual cause: No visibility of progress until the deadline passes, so nobody intervenes on day +2
Looks like: Numbers are final but the pack is not
Usual cause: Reports built on extracts and spreadsheets rather than on live data
How to diagnose it properly
Record start and end time per task for two cycles, per entity. Plot the critical path. The result is usually uncomfortable and immediately useful.
Distinguish effort from elapsed time. Most close days are waiting: for data, for an approval, for another team's run.
Number, value and purpose of manual journals per entity. Recurring, low-value entries are the automation shortlist.
What to capture per task in the diagnostic
Why it matters: Shows whether the task waits or the plan is wrong
Typical finding: Tasks start late because the predecessor finished late, not because of effort
Why it matters: Separates real work from waiting
Typical finding: A two-hour task occupying a full day of the calendar
Why it matters: Builds the critical path
Typical finding: Dependencies that are habit rather than necessity
Why it matters: Sets the target mix
Typical finding: Jobs run manually because “someone has always launched them”
Why it matters: Points at upstream defects
Typical finding: The same five error types every month, in every entity
A useful rule of thumb: if a task cannot be explained in terms of a real accounting judgement, it is a candidate for elimination or automation. Reconciling S/4HANA against itself, re-keying data that exists in a sub-ledger, and rebuilding the same spreadsheet every month all fail that test.
The S/4HANA Foundation: What You No Longer Have to Do
The Universal Journal is the reason a faster close is possible at all. General ledger, controlling, asset accounting and material ledger postings live in one line-item table, with the same document, the same currencies and the same period. Several classic close tasks simply have no object any more.
FI–CO reconciliation
Why it existed: separate tables and periodic transfer between modules. Now: one journal, postings are simultaneous.
Reconciliation ledger run
Why it existed: cross-company and cross-area reconciliation postings. Now: replaced by the single data model.
Profitability analysis alignment
Why it existed: account-based and costing-based results to reconcile. Now: margin analysis is part of the journal.
Rebuilding totals and indexes
Why it existed: aggregate tables kept in step with line items. Now: totals are calculated on the fly.
Waiting for extracts to report
Why it existed: reporting needed data moved to another store. Now: operational reporting runs on live data.
Depreciation posted only at period end
Why it existed: batch-oriented asset accounting. Now: asset postings are journal postings; runs can be executed and reviewed earlier.
Separate closes per accounting principle
Why it existed: parallel valuation handled by separate processes. Now: with parallel accounting, ledger-specific processes run in one framework.
The migration trap: many organisations carried their ECC close calendar into S/4HANA unchanged, including tasks whose only purpose was to reconcile things that are now the same record. Deleting obsolete tasks is the cheapest acceleration available — and it usually takes a review of the task list rather than a project.
Capabilities that change the shape of the close
Real time instead of period end
- Event-based revenue recognition recognises revenue as costs and billing are posted, rather than in a period-end run — decisive for services and project businesses.
- Continuous intercompany matching compares postings as they happen instead of after the fact.
- Predictive and commitment data gives a view of the result before actuals are complete.
One framework instead of many
- Universal allocations replace separate allocation tools with one run, traceable to the journal.
- Accrual management turns accrual calculation and reversal into rule-driven postings.
- Group reporting consolidates on the same data, removing a collection step.
Availability of individual capabilities depends on your release and deployment. Confirm scope against your system before committing a design — the pattern holds, the details move between releases.
Five questions about your own system
- Which release are we on, and which close-relevant capabilities did we skip at migration?
- How many ledgers and valuations do we run, and who actually reads each one?
- Is revenue recognised as events happen or in a period-end run?
- Are allocations still built in an older framework nobody wants to touch?
- Do our close reports read live data, or an extract taken at an unknown moment?
Automating the Work Itself
Task by task, this is where the hours sit and what removes them. The order matters: fix the data and the rule first, then automate the run, then move it earlier in the calendar.
What to do in S/4HANA: Convert repeated manual entries into recurring postings with fixed rules and owners
Effect on the close: Removes preparation and approval effort from every cycle
What to do in S/4HANA: Use accrual management and purchase-order accruals so calculation and reversal follow a rule
Effect on the close: Moves work from day +3 to a monitored rule; fewer spreadsheets from the business
What to do in S/4HANA: Rebuild cost and overhead allocations as universal allocations with traceable results
Effect on the close: One run, one framework, and errors visible immediately
What to do in S/4HANA: Schedule valuation runs as automated jobs with pre-checks on open items
Effect on the close: Removes a late, sequential step
What to do in S/4HANA: Run depreciation earlier in the cycle, with exceptions reviewed rather than full lists
Effect on the close: Frees the critical path for judgement work
What to do in S/4HANA: Monitor and clear during the month; attack the upstream causes with procurement
Effect on the close: Turns a monthly investigation into a small exception list
What to do in S/4HANA: Automate statement import and matching daily
Effect on the close: Day +1 becomes a confirmation, not an exercise
What to do in S/4HANA: Run costing and settlement checks during the month; validate before the close window
Effect on the close: Stops errors appearing on the critical path
What to do in S/4HANA: Validations, substitutions and approval rules with thresholds and deadlines
Effect on the close: Fewer entries, faster approval, cleaner audit trail
Where judgement should stay manual
Litigation, restructuring, bad debt beyond the policy rule — automate the data collection and the posting, not the judgement.
Acquisitions, disposals, contract changes. The goal is that they are the only thing on the reviewer's desk.
The point of closing faster: more time explaining the result, less time producing it.
Choosing what to automate first
Ask: Does it happen every cycle, in every entity?
Prioritise when: High — the payback multiplies across entities
Ask: Does anything wait for it?
Prioritise when: On the path — off-path savings do not change the date
Ask: Is there a real accounting decision inside?
Prioritise when: Low judgement, clear rule
Ask: Would automation run on trustworthy data today?
Prioritise when: Reliable — otherwise fix the source first
Ask: Does it carry a key control?
Prioritise when: Automate with the control redesigned, and tell your auditors early
Sequence matters more than tooling. Automating a task that runs on bad data moves the failure, it does not remove it. Each item above should pass three tests before automation: the data is reliable, the rule is written down, and someone owns the exceptions.
Intercompany: The Biggest Single Win
In most groups, intercompany is the reason the close cannot finish on day +3. Both sides post independently, differences appear only when someone compares them, and the comparison happens after period end — which is exactly the wrong time.
The traditional pattern
Post
Both entities post independently all month
Compare
Someone builds a reconciliation after period end
Chase
E-mails between controllers across time zones
Adjust
Late postings, sometimes in the wrong period
Eliminate
Consolidation waits, then reports a difference anyway
The S/4HANA pattern
Match continuously
Documents matched as they post, by rule and tolerance
Show differences early
Both sides see the same list during the month
Resolve in place
Assignment, comment and automatic adjustment within tolerance
Close reconciliation
A defined step with evidence, before the accounting close
Eliminate cleanly
Consolidation starts with matched data
What makes it work
Design decisions
- Matching rules per document type — invoices, recharges, loans, dividends behave differently.
- Tolerances agreed with group accounting, with automatic adjustment below the threshold.
- A shared calendar: an intercompany cut-off earlier than the accounting cut-off.
- Ownership: one named person per entity pair, not “the team”.
Upstream fixes that pay twice
- Standardise intercompany pricing and document flow so both sides post the same amounts automatically.
- Use group-wide master data for trading partners — most differences start as a wrong partner assignment.
- Automate recharges on a schedule rather than at period end.
- Net settlements so treasury and accounting see the same balances.
Where intercompany differences actually come from
Typical origin: One side posts in the next period
Where to fix it: A shared cut-off, enforced — not negotiated each month
Typical origin: Manual recharges and transfer-price changes
Where to fix it: Standardised pricing and automated document flow
Typical origin: Different rates or rate types
Where to fix it: One group rate source and rate type policy
Typical origin: Trading partner missing or mis-assigned
Where to fix it: Master data rules and posting validations
Typical origin: Recharges nobody agreed to
Where to fix it: Service-level agreements between entities, priced in advance
What to measure
Open differences
Value and count at day +1, +3 and +5
Match rate
Share matched automatically, by rule
Ageing
Differences older than one period
Late adjustments
Intercompany postings after the cut-off
The organisational part: matching technology settles the arithmetic; it does not settle who concedes. Groups that succeed write down a difference resolution policy — who adjusts, within what tolerance, by when, and what happens when the two sides disagree — and give group accounting the casting vote before the deadline, not after it.
Orchestrating the Close
A spreadsheet checklist tells you what should happen. An orchestration tool makes it happen: tasks with owners, dependencies and deadlines, jobs that trigger the next step automatically, and a live view of every entity's progress. In the SAP world this is SAP Advanced Financial Closing, the successor to the Financial Closing Cockpit.
What orchestration gives you
- Templates reused across entities and cycles, so the close is designed once and repeated.
- Dependencies: a task starts when its predecessor completes, rather than when someone notices.
- Automation: scheduled jobs run unattended and report their own success or failure.
- Real-time status across subsidiaries — the late entity is visible on day +2, not at the deadline.
- Evidence: who did what, when, with the result attached — the audit trail comes for free.
How to design the template
- Start from the measured close, not the documented one.
- Model the real dependencies, then challenge each one: many are habits, not constraints.
- Mark every task automated, semi-automated or manual, and set a target to shift the mix.
- Give each task an owner, a duration and a deadline expressed in working days.
- Separate group-mandatory tasks from local ones so entities can adapt without breaking the model.
From checklist to orchestration
What it looks like: A file per entity, updated by e-mail
What it costs you: No visibility until it is too late to act
What it looks like: One list with owners and dates
What it costs you: Better transparency, still manual execution and chasing
What it looks like: Templates, dependencies, scheduled jobs, live status
What it costs you: Setup effort and template governance — repaid every cycle
What it looks like: Most tasks run during the period; the close confirms rather than produces
What it costs you: Requires process change, not just tooling
What a task looks like in a good template
Owner: Treasury ops
Starts when: Daily, scheduled
Mode: Automated, exceptions reviewed
Owner: Entity controller
Starts when: Continuous; hard cut-off day −1
Mode: Automated with tolerance
Owner: GL accountant
Starts when: After AP cut-off
Mode: Rule-based, reviewed
Owner: Fixed assets
Starts when: After asset cut-off
Mode: Automated job
Owner: Controlling
Starts when: After cost postings complete
Mode: Automated, trial run mid-month
Owner: Finance manager
Starts when: After allocations
Mode: Manual, exception-based
A caution: orchestration makes a good close faster and a bad close visible. If the template simply digitises today's checklist — including the tasks that exist to reconcile S/4HANA with itself — you get better reporting on the same duration. Redesign first, then automate.
One template with local variants beats twenty independent calendars — and makes benchmarking between entities possible.
Closing steps in other systems can be modelled as tasks too, so the plan reflects reality rather than the ERP boundary.
Each cycle produces timing data. Use it to move one task earlier, automate one more, and delete one — every month.
Consolidation and Reporting
For a group, the close is not finished when the entities are finished. Historically, consolidation added a week: collect data, validate it, chase corrections, eliminate, report. Most of that sequence can now overlap with the entity close instead of following it.
What changes with group reporting on the same data model
- No collection step for entities on the same system — the data is already there, at line-item level.
- Continuous consolidation: run eliminations during the month to see the group position early.
- Validation rules that reject bad data at the entity, before it becomes a group problem.
- Drill-down to the journal, so a group question does not become an e-mail to a controller.
What still needs design
- Entities on other systems: a defined interface and a data-quality contract.
- Currency translation, minority interests and equity method — accounting decisions, not settings.
- The boundary between statutory and management reporting, and which one drives the deadline.
- Group master data: one chart of accounts mapping, one trading-partner list, one calendar.
Reporting: stop rebuilding the pack
Usual cause: Spreadsheet assembly from exports
Fix: Report from live data; keep commentary, drop re-keying
Usual cause: Several extracts taken at different moments
Fix: One source, one definition per KPI, with owners
Usual cause: Manual variance analysis
Fix: Automated variance and exception reporting on the journal
Usual cause: One deadline for both
Fix: Publish management figures earlier, with a clear “subject to close” status
Validations worth building at the entity
At the entity, before submission
- Trading partner present on every intercompany account posting.
- Balance sheet accounts reconciled and flagged, with ageing on open items.
- Intercompany differences below the agreed tolerance before submission.
- Mandatory dimensions filled: profit centre, segment, functional area.
- No postings in the period after the entity declares it closed.
- Local-to-group chart of accounts mapping complete for new accounts.
Who does what, and when
Entity: Posts, reconciles and passes validations
Group: Publishes rules and monitors progress
Timing: Continuous, hard stop at submission
Entity: Declares the period closed
Group: Confirms completeness across entities
Timing: Day +2 to +3
Entity: Resolves flagged differences
Group: Runs eliminations and currency translation
Timing: Day +3 to +4
Entity: Answers drill-down questions
Group: Analyses, validates and signs off
Timing: Day +4 to +5
A practical target: a group flash view available on day +2 or +3 with known gaps, a complete management view by day +4, and the statutory pack when the statutory work genuinely requires — rather than forcing all three onto one date and making the earliest information as late as the latest.
Making It Stick: Continuous Accounting
Technology shortens tasks. Only process change shortens the calendar. The principle is simple and hard: do the work when the transaction happens, not when the period ends.
What moves before period end
Traditional timing: Day +1 to +2
Continuous timing: Daily, automated; day +1 is a confirmation
Traditional timing: Day +2 to +4
Continuous timing: Continuous, with a cut-off before period end
Traditional timing: Day +2 to +3, from spreadsheets
Continuous timing: Rule-based during the month, reviewed at period end
Traditional timing: Day +2
Continuous timing: Acquisitions and retirements processed as they occur
Traditional timing: Day +3 to +4
Continuous timing: Trial run mid-month; final run early in the close
Traditional timing: Discovered during the close
Continuous timing: Validations at posting; a daily exception list
The habits that hold the gain
Agreed thresholds for adjustments and for what must be reviewed at all. Without them, everything is reviewed and nothing is faster.
Posting periods opened and closed on schedule, with a short, documented exception path. A soft period lock is worth days.
Reviewers see what breaks a rule or a tolerance. The evidence that everything else passed is generated, not assembled.
Soft close, hard close
A fast, estimate-tolerant view for management: allocations and accruals on rules, materiality applied, published early with a clear status.
The full statutory close with final valuations, provisions and disclosures — necessary, but not necessarily the deadline for every number.
Forcing both onto one date makes management information as late as the slowest statutory task, every single month.
The KPI set worth tracking
Working days to close
To entity trial balance, to group pack — measured, not estimated
Automation share
Tasks automated / semi-automated / manual, by entity
Manual journals
Count and value per cycle, and how many were recurring
Post-close adjustments
Entries after the close and reopened periods — the quality check
Who owns the close: a faster close needs a single accountable owner with authority across entities — someone who can hold a cut-off, decide an intercompany difference and say no to a late adjustment. Where that role is unclear, the calendar drifts back within two quarters, whatever the system does.
How 30 Advisory Can Help
A founder-led boutique specialised in S/4HANA Finance optimisation, SAP DRC & e-invoicing compliance and CFO/CIO strategic advisory. On fast close we work on the process and the system together — because separating them is why most acceleration projects disappoint.
Close diagnostic: task-level timing for two cycles, critical path, manual journal analysis, automation candidates.
Baseline KPIs and a target calendar agreed with the CFO and the entities.
Design the target close: task list rebuilt, obsolete tasks removed, dependencies challenged, owners named.
Capability fit-gap against your release: accruals, allocations, intercompany matching, revenue recognition, group reporting.
Configure and test the accelerators; build the orchestration template with automation where it is safe.
Fix the upstream causes — master data, GR/IR, intercompany pricing — that generate close work.
Run two closes side by side with the new calendar, measure, adjust, then cut over.
Train reviewers on exception-based working and hand over the KPI pack.
Post-close reviews each cycle: one task earlier, one more automated, one deleted.
Keep the close design aligned with new releases, new entities and new compliance obligations.
Typical deliverables
Close diagnostic
Critical path, bottlenecks and a quantified opportunity per task.
Target close design
Task list, calendar, owners and the automation mix.
Configuration & template
Accelerators implemented and the orchestration model built.
KPI pack
Measurement that survives the project and shows drift early.
Engagement models
Fixed Price / SoW — milestone-based delivery.
Partnering — independently or alongside your system integrator.
A focused start
Founder-led
Finance + SAP depth
Multi-country: Italy, Türkiye, Spain
Boutique agility
Roadmap, Pitfalls and Next Steps
A realistic roadmap
Diagnose: measure two cycles at task level; count manual journals; map the critical path; agree the target calendar
You should see: an evidence-based list of where the days go
Quick wins: delete obsolete tasks; automate recurring journals; daily bank reconciliation; intercompany cut-off before period end; period discipline
You should see: one to two days, usually without configuration projects
Structural: intercompany matching, accruals, allocations, revenue recognition, orchestration template, group reporting alignment
You should see: the close becomes repeatable and visible across entities
Sustain: post-close review each cycle; KPI tracking; new entities onboarded onto the template
You should see: the calendar holds — and keeps improving slowly
Pitfalls we see repeatedly
Eight ways a faster close slips back
- Automating the old close instead of redesigning it — faster tasks, same calendar.
- No single owner with authority across entities, so cut-offs are negotiable.
- Thresholds never agreed, so everything is material and everything is reviewed.
- Upstream causes ignored — GR/IR and intercompany differences are made during the month.
- Too many ledgers and valuations added without asking who reads them.
- Reporting left on spreadsheets, so the numbers are ready before the pack is.
- No measurement, so the gain quietly erodes within two quarters.
- Close and compliance planned separately, then colliding in the same week.
The compliance overlap: statutory reporting, e-invoicing statuses and audit files all land in the same calendar as the close. Designing the close without them — or designing them without the close — is how finance teams end up with two competing month-ends. The same data model, the same master data and the same monitoring discipline serve both.
Next steps
Six steps to start with
- Measure the next two closes at task level, per entity.
- Delete what the Universal Journal made obsolete.
- Set an intercompany cut-off before period end and name owners.
- Automate the recurring journals and daily bank reconciliation.
- Agree materiality thresholds for adjustment and review.
- Build the orchestration template from the measured close, not the documented one.
Product capabilities: SAP documentation and community material on the Universal Journal, SAP Advanced Financial Closing, intercompany matching and reconciliation, accrual management, universal allocations and SAP S/4HANA Finance for group reporting. Availability and naming differ by release and deployment option — confirm scope for your landscape with SAP before committing a design. Practice: the bottleneck patterns, sequencing advice and KPI set reflect 30 Advisory's delivery experience on S/4HANA Finance engagements; they are guidance, not a guarantee of a specific result.
Prepared by 30 Advisory, September 2026. Information only — not accounting, audit or tax advice. Any close redesign should be reviewed with your auditors before implementation, particularly where it changes controls, cut-offs or materiality.
Want to Know Where Your Close Days Go?
We'll review your close calendar and map the bottlenecks in a 1-hour diagnostic session.
Schedule Assessment (1 hour)