Reporting & analytics
If the real numbers live in a spreadsheet, the ERP is not finished
Almost every business running SAP Business One still assembles its management pack in Excel. The data is in the system; it is just not in a shape anyone can use. That is a solvable problem, and solving it is usually the highest-value work available on an existing installation.
- Crystal Reports and query-based reports
- Native SQL Server and SAP HANA
- Reports your team can run themselves
The situation
How reporting ends up outside the system
The chart of accounts does not match the report
The management pack needs a structure the ledger was never designed to produce, so every month someone maps one to the other by hand.
Standard reports nearly work
They are close but not right — wrong grouping, missing a dimension, no comparative — so they get exported and edited, every time.
Only one person can produce it
The pack depends on a workbook that one person built and maintains. When they are away, reporting stops.
The numbers diverge
The spreadsheet version and the system version disagree, and reconciling them has become a monthly task in its own right.
Queries slow the system down
Reports written without regard for how the database executes them, running at month-end and affecting everyone else.
Nobody trusts the dashboard
A dashboard was built once, its figures were questioned, and now everyone quietly uses their own numbers instead.
How we do it
We start from the decision, not the data
The useful question is not what the system can report. It is what somebody is about to decide, and what they need in front of them to decide it well.
So we start with the management pack and the questions directors actually ask, then work backwards to what the system has to hold to answer them. Often that surfaces a structural issue — a chart of accounts that cannot produce the analysis the board wants, or a missing dimension on transactions — and no amount of report writing fixes that. Correcting the structure is usually cheaper than maintaining the spreadsheet that compensates for it, and we will tell you when that is the case.
Reports themselves are written natively for your database. On Microsoft SQL Server that means T-SQL, views and stored procedures; on SAP HANA it means SQLScript and modelled views. This matters more than it sounds: a query written for one does not simply move to the other, and reports written without regard for the platform are the usual cause of month-end slowdowns. We write them to execute efficiently and we test them against real data volumes rather than a demonstration company.
Everything we build is handed over so your team can run it, change the parameters and understand where the figures come from. A report that only its author can maintain is a dependency, not an asset — and reporting dependencies are how businesses end up back in Excel.
What we deliver
- Reports that run inside SAP Business One
- Written natively for your database platform
- Tested against real data volumes
- Documented so your team can maintain them
What we build
Reporting work we take on
Crystal Reports layouts
Invoices, statements, orders, picking notes and delivery documents — branded, accurate and printing correctly the first time.
Query-based reports
Reports built in Query Manager and made available to the right users inside the client, with parameters they can set themselves.
Management reporting
The monthly pack produced from the ledger: profit and loss by dimension, balance sheet, margin analysis, aged debt and creditors.
Dashboards
Operational dashboards for the handful of figures people check daily, built on definitions everyone has agreed to.
Reporting structure review
Assessment of whether your chart of accounts and transaction dimensions can actually produce the analysis you want.
Query performance
Investigation and tuning of reports that slow the system down, including indexing and rewriting for the platform you are on.
How it works
From management pack to working reports
Define
We start with the decisions being made and the questions asked, then agree the definitions — what counts as revenue, which date drives the period, how margin is calculated.
- Reporting requirements
- Agreed definitions
- Audience per report
Assess
Whether the data exists in the structure needed. Where it does not, we say so and set out what would need to change.
- Chart of accounts review
- Dimension availability
- Data quality check
Build
Written natively for your database, inside SAP Business One where possible so people run them where they already work.
- Native SQL or SQLScript
- In-client delivery
- Parameterised
Reconcile
Every report tied back to the ledger or the source figures, so the first question a director asks has an answer.
- Tie-back to ledger
- Variance explained
- Sign-off by finance
Hand over
Documentation of the definitions and the logic, and training so your team can change parameters and maintain them.
- Report documentation
- User training
- Change guidance
Technical detail
Reporting across both database platforms
SAP Business One runs on Microsoft SQL Server or on SAP HANA. Reporting is where that choice is felt most, and code written for one does not simply move to the other.
Microsoft SQL Server
- T-SQL queries, views and stored procedures
- Execution plan analysis and index design
- Common table expressions and window functions
- Reporting against a replica where volume requires it
SAP HANA
- SQLScript procedures and table functions
- Calculation views and modelling
- Column-store aware query design
- HANA-specific analytical functions
Crystal Reports
- Document layouts for all marketing documents
- Report design and sub-reports
- Parameters, formulas and grouping
- Integration with the SAP Business One client
- Print sequences and batch printing
In-client reporting
- Query Manager and Query Generator
- User-defined queries with parameters
- Formatted searches driven by queries
- Authorisation on report visibility
- Query-based alerts on exceptions
Management reporting
- Profit and loss by cost centre and dimension
- Balance sheet and trial balance
- Margin and gross profit analysis
- Aged debtors and creditors
- Stock valuation and movement
- Budget against actual
Performance
- Query tuning and rewriting
- Index review and creation
- Scheduling heavy reports off-peak
- Aggregation where detail is not needed
- Testing against production data volumes
What changes
What good reporting changes
The pack comes out of the system
Management reporting produced from the ledger rather than rebuilt monthly in a workbook that only one person understands.
One version of the numbers
Agreed definitions applied consistently, so meetings stop being an argument about whose figures are right.
Reporting survives absence
Reports documented and handed over, so the month does not depend on one person being available.
Faster close
Time currently spent assembling and reconciling reports goes back to the finance team.
A system that stays quick
Reports written for the platform they run on, so month-end reporting does not slow everyone else down.
What to expect
The shape of reporting work
Single report or layout
Half a day to three days, depending on complexity and how clearly the definitions are already agreed.
Management pack
Two to six weeks, including agreeing definitions, building, reconciling to the ledger and handover.
Reporting structure review
Three to five days, ending in a written assessment of whether your current structure can produce the analysis you want.
Dashboards
One to three weeks, and best done after the underlying reports are agreed rather than before.
Performance investigation
Usually a few days to identify and correct the specific queries causing month-end slowdowns.
Where the honest answer is that your chart of accounts cannot produce what you want, we will say so before quoting report writing that would only paper over it.
Fit
Whether this is the right conversation
A good fit if
- Your management pack is assembled in Excel every month
- Standard reports are close but never quite right
- Only one person can produce the numbers
- Reports and the ledger disagree and nobody knows why
- Month-end reporting slows the whole system down
- You want dashboards people will actually trust
Probably not us if
- You want a dashboard before the underlying definitions are agreed
- The data needed simply is not being captured, and you do not want to change that
Common questions
Questions we are asked before a project starts
Can you build reports if we are on SAP HANA rather than SQL Server?
Yes, and we write for the platform rather than porting. HANA reporting uses SQLScript and modelled views and rewards a different query design from SQL Server’s T-SQL. Reports moved between the two without being rewritten are a common source of poor performance, so we write natively for whichever you are on.
Why do our reports and our ledger disagree?
Usually one of three reasons: the report uses a different date basis from the ledger, it includes or excludes document types inconsistently, or it was written against tables in a way that misses postings. Every report we build is tied back to the ledger and signed off by finance before handover, precisely so this question has a documented answer.
Can our team maintain the reports afterwards?
That is the intention. Reports are delivered with documentation of their logic and definitions, and we train your team to change parameters and make straightforward amendments. A report only its author can maintain is a dependency rather than an asset.
Do we need a separate business intelligence tool?
Often not. A great deal of what businesses buy BI tools for can be produced inside SAP Business One, where people already work and where the figures reconcile to the ledger by construction. If your requirements genuinely justify a separate tool, we will say so — but we would rather exhaust what you already own first.
Our reports slow the system down at month-end. Can that be fixed?
Nearly always. It is usually a small number of queries scanning far more data than they need, and the fix is rewriting them for the platform, adding appropriate indexes, or scheduling the heavy ones off-peak. It is normally a few days of work with a very noticeable result.
Related
Where to go next
ERP + Accounting
Why reporting problems are usually structural, and what changes when one team owns both sides.
Read more
Management Accounts
Having us produce the monthly pack rather than only building the reports behind it.
Read more
Send us your management pack.
Show us the spreadsheet your finance team rebuilds every month and we will tell you how much of it could come straight out of the system — and what would have to change for the rest.
Or call +44 7493 619245 — Monday to Friday, 09:00–17:30.