Budgeting and forecasting
Annual budget, rolling forecast and long-range plan running as one connected process rather than three disconnected exercises — with seeding, submission, workflow and locking designed rather than improvised.
Planning & reporting
SAP Analytics Cloud for Finance Planning and Reporting.
We design, implement and optimise SAP Analytics Cloud for budgeting, forecasting, financial planning and management reporting. Capability is rarely the constraint — what separates a solution finance relies on from one it works around is model design, architecture and process.
Sound familiar?
What we usually hear first.
- Our planning process is still heavily spreadsheet-driven.
- We have SAC, but finance adoption is low.
- Our SAC models have become slow and difficult to maintain.
- We want to move planning out of BPC but do not know whether SAC supports our requirements.
- We have Group Reporting but do not know how SAC should fit into the reporting architecture.
- Management reporting takes too much manual effort every month.
- Different teams have different versions of the same KPI.
- Our SAC implementation reproduced our old processes rather than improving them.
Each of these is a symptom rather than a diagnosis, and they rarely have the cause people assume. That is why most of our SAC work starts with an assessment or a health check rather than a build.
What finance uses it for
Six things worth building SAC around.
Grouped by what finance is trying to do rather than by product feature. The objective is a model that explains the business — not a spreadsheet reproduced at enterprise scale.
Driver-based and scenario planning
Volume and price, headcount and cost, capacity and spend. Enough drivers that the plan explains the business, and not so many that the model becomes harder to explain than the thing it models.
Integrated financial planning
Profit and loss, balance sheet and cash flow in one model, so a change in revenue assumptions moves working capital and cash without anyone rebuilding a spreadsheet bridge.
Allocations and cost planning
Structured allocation logic a finance user can trace a number back through — including the decision about whether that logic belongs in SAC at all.
Management reporting and variance analysis
Actual, budget and forecast in one analytical framework, with one agreed definition per KPI, rather than three exports reconciled by hand each month.
Board and executive reporting
Reporting weighted by financial materiality, with variance that reads at a glance and drill-down only where it answers a real follow-up question.
Where SAC fits
Four questions that decide how well SAC ages.
These get answered either deliberately at the start, or accidentally during the build. The first is considerably cheaper.
Live connection or imported data?
Less a spectrum than a fork: planning in a public model requires imported data, while a live connection preserves a single source of truth and rules most modelling and planning out. The choice should follow from latency, security, transformation and planning requirements — not from a blanket preference.
Where should finance logic live?
Calculations split across S/4HANA, Datasphere, BW and SAC stories are how definitions drift apart. We decide which layer owns which logic, and hold that line through delivery.
How do actuals, budget and forecast meet?
Integration between ACDOCA, ACDOCP, Group Reporting results and planning models, so actual-versus-budget-versus-forecast is structural rather than assembled by hand each month.
Which platforms are actually required?
SAC, Datasphere, BW/4HANA and Business Data Cloud overlap. Not every organisation needs all of them, and deciding deliberately is cheaper than discovering the answer during the build.
Planning edge cases
A planning model is tested by these, not by the base case.
Every planning solution handles a clean annual budget. These are the ten situations that decide whether it is still trusted in year three.
Multiple currencies and planning rates
Local, transaction and group currency each need a stated purpose, planning rates need an owner, and rates have to stay consistent across versions — or every comparison becomes an argument.
Mixed granularity
Revenue by product, workforce by position, CAPEX by project and the financial statements by account. Forcing all four to one grain is the most common cause of a model nobody wants to use.
Actuals that arrive late, or restate
Seeding, cutover periods, forecast refresh and version governance. A model that assumes actuals are final will break the first time they are not.
Top-down targets and bottom-up submission
Usually both at once. The design has to support target setting while preserving accountable operational input, and reconcile the two without one silently overwriting the other.
Cross-model dependencies
When separate models should genuinely interact, and when connecting them only creates a fragile dependency that fails at the worst point in the cycle.
Allocations at scale
Transparency, runtime and traceability degrade together. Past a certain volume the question stops being how to write the allocation and becomes which layer should run it.
Large dimensionality and sparsity
Model grain and performance are the same decision viewed from two directions. Far cheaper to settle at design than to discover during user testing.
Security by entity, cost centre and version
Data access, planning ownership and workflow are one design problem. Treating security as a configuration task at the end reliably produces a model people cannot use.
Excel-heavy finance users
Some contributors will never plan in a browser, and pretending otherwise costs adoption. Microsoft Office integration can carry input and write-back where that is the honest answer.
Group Reporting actuals with SAC plan
Aligning actual, plan and forecast across two platforms means agreeing hierarchies, grain and reporting ownership up front — not reconciling them afterwards.
Model design
The decisions that determine performance and maintainability.
- Model granularity and data volumes
- Dimensions, measures, accounts and time
- Version and category strategy
- Currency and organisational structures
- Planning levels and disaggregation
- Calculation, data action and multi-action design
- Master data and hierarchy ownership
- Security and workflow, designed in rather than bolted on
Data actions and multi-actions automate the repetitive parts of a planning cycle — seeding versions, carrying assumptions forward, calculating drivers, running allocations, translating currency. Used well they remove work. Used carelessly they become the part of the solution only their author can maintain, which is the specific outcome we design against.
Automation should simplify the process while keeping the calculation auditable. Where finance genuinely works best in Excel, SAC's Microsoft Office integration can carry planning input and write-back rather than forcing everything into the browser.
Typical engagements
Scoped to the decision in front of you.
| Engagement | Typical duration | Primary deliverables |
|---|---|---|
| SAC Planning Assessment | 2–4 weeks | Current-state review, requirements, fit assessment, target process and architecture, roadmap |
| SAC Planning Solution Design | 3–8 weeks | Blueprint, model architecture, driver/version/currency design, workflow, integration, reporting and test approach |
| SAC Reporting Design | 2–6 weeks | Reporting requirements, KPI model, data sourcing, story and dashboard design system, governance |
| SAC Health Check | 1–3 weeks | Architecture, model and performance review, findings, quick wins and a remediation roadmap |
Durations are indicative and depend on the number of planning models and processes in scope, how many contributors are involved, and the availability of your finance and IT stakeholders.
BPC to SAC
Rebuilding your BPC model in SAC is usually the wrong starting point.
Organisations leaving BPC often assume the existing planning models should simply be recreated. That reproduces years of accumulated complexity inside a new platform and inherits every workaround built around limitations that no longer exist.
The useful exercise is to decompose what BPC actually does for you, separate genuine requirements from inherited habit, and then decide where each capability belongs — including the possibility that SAC is not the right destination for some of it.
| BPC capability | Typical successor |
|---|---|
| Budgeting | SAC Planning |
| Rolling forecast | SAC Planning |
| Driver-based planning | SAC Planning |
| Management reporting | SAC |
| Legal consolidation | SAP Group Reporting or an alternative platform |
| Management consolidation | Group Reporting, SAC or an alternative, depending on requirements |
| Allocations | SAC, Group Reporting or the source system, depending on use case |
| Data collection | SAC, Group Reporting Data Collection or the integration layer |
| Excel input | SAC Microsoft Office integration where appropriate |
| Executive dashboards | SAC |
| Workflow | SAC planning process design |
Indicative only. The right answer depends on your requirements, and working it out is the substance of the BPC Modernisation & Platform Assessment.
How we approach SAC
Six things you can hold us to.
Finance first
We start with the decisions, processes and reporting finance needs to support — not with the platform.
Architecture before build
Where data, calculations, planning logic and reporting live is settled before models and dashboards are built.
Simplify before migrating
Legacy processes get challenged before they are reproduced. Not everything in the old system deserves to survive.
Design for ownership
Your team should be able to understand and operate the solution after we leave. That constrains how clever the design is allowed to be.
Reporting with purpose
Every dashboard, table and visual should answer a business question someone is actually asking.
Integrate where it adds value
Planning, consolidation and reporting connect where the process requires it — and stay separate where integration would only add dependency.
Related
Where this sits.
- SAC Planning Assessment — deciding whether SAC fits, and what the target should be
- SAC Health Check — for a solution already live that finance has started working around
- Finance Data & Reporting Architecture — where SAC sits relative to everything else
- Training — enabling the team that will operate it
- About Radixa — how we work, and the experience behind the advice
Next step
Describe the planning process, not the platform.
How many contributors, how many cycles, where the spreadsheets sit and what makes the current process painful. That is enough for us to say which engagement fits — or whether SAC is the right answer at all.