SAC is the short form almost everyone in an SAP landscape uses for SAP Analytics Cloud. This page explains what the product is, the three jobs it does in one place, how connections, models and stories fit together, when to read data live and when to import it, and where it sits beside S/4HANA and SAP Datasphere.
In an SAP context, SAC is the short form of SAP Analytics Cloud. It is a software as a service analytics product: you reach it through a browser, SAP runs the infrastructure on SAP Business Technology Platform, and there is no client to install and no application server for a Basis team to patch. That is the direct answer to the question most people type. The more useful half is what follows, because SAC is not simply a cloud version of an older reporting tool.
Most analytics products do one job. A dashboard tool visualises data that somebody else prepared. A planning tool collects budget numbers. A statistics package builds forecasts. SAC does all three on top of one modelling layer, in one tenant, against one set of dimensions. That single design decision is what people are pointing at when they say the variance report and the budget behind it live in the same place.
One ambiguity worth clearing up, since it is the reason some people arrive here confused. SAC is used as an abbreviation for other things elsewhere in software. Inside an SAP landscape, in an SAP job advertisement, or on a project call, it means SAP Analytics Cloud. If a colleague means the older on premise reporting stack, they will say BusinessObjects or Web Intelligence instead.
SAC has a small vocabulary, and the whole product makes sense once you have it. Everything starts with a connection, which points at a source system or a file. On top of a connection sits a model, which is the semantic layer where dimensions, hierarchies, measures, units and currency conversion are defined. On top of a model sits a story, which is what the business actually opens on a Monday morning.
| Object | What it is for |
|---|---|
| Connection | The link to a source system or file, either live or configured to import data on a schedule |
| Model | The semantic layer: dimensions, hierarchies, accounts or measures, units, currency conversion and data access control |
| Story | The report itself: pages of charts, tables, geo maps, filters and input controls, laid out responsively for laptop and mobile |
| Analytic application | A story-like artefact with scripting behind it, for interaction beyond what a story can express |
| Digital boardroom | A presentation layer over stories for management meetings, built for a large screen and live drill down |
| Calendar | Tasks, owners, due dates, reviews and approvals for a planning cycle, so a budget round has a visible state |
| Data action | A repeatable step that writes back to a planning model: copy a version, apply a driver, run an advanced formula |
| Allocation | A rule that spreads a value across a dimension, for example overheads across cost centres by headcount |
| Predictive scenario | A Smart Predict model for classification, regression or time series forecasting, trained on data already in the tenant |
Nearly all the difficult work is in the model. A story built on a clean model with sensible hierarchies almost assembles itself, while a story built on a model with the wrong granularity or missing security will be slow, wrong, or both. Data access control on the model is what decides whether a branch manager sees only their own branch, and it is the item most often left until the week before go live.
This is the first real decision on any SAC project and it is the question interviewers ask most often, so it is worth being precise rather than approximate about it.
With a live connection, nothing is copied. When a user opens a story, SAC sends the query down to the source system, the source executes it and returns an aggregated result. The numbers are as current as the source itself, the source keeps control of authorisations, and there is no replication to schedule, monitor or explain to an auditor. Live is the normal choice for SAP S/4HANA, SAP BW/4HANA, SAP HANA and SAP Datasphere. Where the source sits on premise, an SAP Cloud Connector or the equivalent component sits between the tenant and the system so that the traffic can reach it safely.
With an imported model, data is loaded into the tenant on a schedule. That allows the things a live connection cannot do: cleaning and wrangling on the way in, blending sources that share no common system, and planning on data whose source is not planning enabled. The trade is freshness and governance. The numbers are only as good as the last successful refresh, and you now hold a copy of data that somebody has to secure and justify.
| Question | Live connection | Imported model |
|---|---|---|
| Where the data sits | In the source system | Copied into the SAC tenant |
| When the query runs | In the source, as the story opens | Against the copy already loaded |
| Freshness | Current with the source | As current as the last successful schedule |
| Transformation | Limited, do it in the source or in Datasphere | Full wrangling and cleaning on import |
| Planning | Restricted, depends on the source | Fully supported |
| Blending sources | Constrained | Straightforward |
| Authorisations | Enforced by the source system | Rebuilt inside SAC as data access control |
The rule most teams settle on is simple enough to state in a sentence: keep governed financial and operational reporting live on the source of truth, and import only what genuinely has no live path, such as a workbook from a subsidiary or a feed from a system outside the SAP estate.
S/4HANA already reports on itself. CDS views expose the transactional tables with business meaning attached, Fiori analytical applications and the query browser let a user run and adjust those queries, and KPI tiles surface a single number on the launchpad. Embedded analytics of that kind is genuinely good for operational reporting inside one system, and it keeps no copy of the data. What it does not do is combine that system with the rest of the landscape, or carry a plan.
SAP Datasphere is the layer that answers the first of those. It is the cloud data warehouse and semantic layer where data from S/4HANA, from BW, from databases outside SAP and from files is harmonised into governed views, with the business semantics preserved rather than flattened into columns. SAC then reads those views live. The sentence you will hear on a modern project is that Datasphere models the data and SAC consumes it, and the two are designed to be used together.
Plenty of Indian landscapes still run SAP BW or BW/4HANA, and SAC connects live to those too, so reporting can move to the cloud before a warehouse migration is finished. BusinessObjects usually keeps the formatted, pixel-precise and operational reports for a good while longer, which is why so many teams describe their estate as both at once rather than one replacing the other.
If you are deciding what to study, the useful observation is that every one of those paths begins in the source system rather than in the tool. That is why SAC turns up on job descriptions as a line item next to a module rather than as a role of its own, and why the SAP courses are the sensible entry point for most people reading this.
The planning half of SAC is where it differs most from other analytics tools, and it is also where the claim is most often overstated. It does not replace every spreadsheet. It replaces one specific and expensive spreadsheet: the budget workbook that gets emailed around a company, versioned by filename, consolidated by hand and reconciled in a panic the week before the board meeting.
What you should not promise a finance team is that the spreadsheet disappears. Ad hoc analysis, a model one person owns for a fortnight, and anything whose structure changes every month are all still faster in Excel. SAP effectively concedes this in the product: it publishes an add-in for Microsoft Office so that contributors can work in a familiar grid while the numbers are read from and written back to the SAC model.
The reason finance people take to SAC planning quickly is that the model mirrors what they already know. Cost centre and profit centre planning, internal orders, statistical key figures and profitability analysis all have direct counterparts in the planning model. That is why a consultant with real SAP FICO depth tends to design a better planning model than a tool specialist who has never sat through a month end close.
Be straightforward about this, because it changes what is worth spending money on. SAC is a skill layer rather than a starting point. It rests on two other things: knowledge of the business process that produces the numbers, and ordinary data literacy, meaning modelling, granularity, aggregation, joins, and the judgement to design a chart that answers a question rather than decorating a slide.
There are two honest doors into it. The first is the functional route: you already work in, or are training for, an SAP module, most often finance, and you add SAC as the reporting and planning skin over the module you understand. The second is the analyst route: you are already fluent in data modelling, SQL and visualisation, and you learn the SAC vocabulary of connections, models, stories, versions and data actions on top of that fluency. Both routes end in the same place. Neither starts with the tool.
To be plain about our own position: Cokonet does not currently run a standalone SAP Analytics Cloud course, and we would rather write that here than let a page imply otherwise. What is genuinely useful preparation is already on the site. The module training under SAP courses covers the process knowledge, and the data analytics course covers the modelling, SQL, visualisation and dashboard design that transfer to SAC and to every other business intelligence tool on the market. SAP publishes its own documentation and a trial of the product, and the concepts in this article are the ones worth looking for the first time you open it.
None of the three pages below is an SAP Analytics Cloud course, and this page is not a way of selling you one. They are the two foundations the skill rests on: the SAP process knowledge that produces the numbers, and the analyst craft that turns numbers into something a business will act on.
The modules that produce the data SAC reports on and plans against, from finance and controlling through to logistics and HR.
Explore SAP → SAP FICOThe finance and controlling ground that most SAC planning models are built on: cost centres, profit centres, internal orders and profitability analysis.
View course → Data AnalyticsModelling, SQL, visualisation and dashboard design, the analyst skills that transfer to SAC and to every other business intelligence tool.
View course →