SAP Business One is the system most small and midsize companies inside a wider SAP estate end up running, and it has earned that position. SAP maintains dozens of country localisations in one application and commits to at least five years of mainstream maintenance per release family — a substantial commitment, met for over two decades. Of every system in this series, Business One is the most likely to arrive already surrounded by other systems — which makes what sits above it more pressing than usual.
At a glance
| System name | SAP Business One — SAP’s term is an ERP solution for small and midsize companies |
| Vendor | SAP SE, Walldorf, Germany. Sold, implemented and supported through SAP partners |
| Markets | Global — dozens of country localisations, with Slovakia, Czechia and Poland localised by SAP itself |
| Category | The entry line of SAP’s ERP range, below SAP Business ByDesign and SAP S/4HANA |
| Product lines | SAP Business One on Microsoft SQL Server · SAP Business One, version for SAP HANA. Same application, same schema, different engine |
| Database / data access | Microsoft SQL Server 2019/2022 on the SQL line; SAP HANA 2.0 under SUSE or Red Hat Linux on the HANA line. One database per company. We read through a dedicated read-only login; before design, we ask your SAP partner or licensing contact to confirm the read against your agreement’s terms |
| Deployment | On-premises · partner-hosted private cloud · SAP Business One Cloud, a partner-operated multi-tenant landscape. One company database per legal entity, plus one shared SBO-COMMON holding version and licence information only |
| Integration | Service Layer — REST and JSON over OData v4, with an SQLQueries endpoint · DI API and DI Server · integration framework (B1if), included with the licence · direct read-only SQL or SQLScript against the company database |
| Payroll | Outside Business One — employee master data in Human Resources, payroll in a partner add-on or a separate system, including in Slovakia, Czechia and Poland |
| Vendor reporting | SAP Crystal Reports with a designer licence under maintenance · Query Manager · financial report templates · on HANA: semantic-layer calculation views and pervasive analytics |
| Typical user | SAP states only “small and midsize companies” and publishes no turnover band; its own road map counts subsidiaries as a distinct segment of the base |
| Official | sap.com — SAP Business One · help.sap.com documentation |
What SAP Business One is
SAP Business One is SAP’s ERP for companies that need a complete business system rather than accounting software, and that are not large enough for an enterprise suite. General ledger, receivables and payables, banking, fixed assets, purchasing, sales, inventory, production, MRP, service and CRM — one application, one database per company.
Where it sits in SAP’s range explains how it shows up in practice: Business One at the entry, Business ByDesign above it, S/4HANA above that. It is not a reduced S/4HANA — it is a separate product on its own code base, acquired in 2002, which is why it implements in weeks with a local partner and why its data model looks nothing like the rest of the SAP portfolio.
Version 10.0 shipped in 2020 and has been extended through dated feature packages since. SAP’s published maintenance table currently puts 10.0 in mainstream maintenance until 31 December 2026, with version 11 to follow. A stated lifecycle and a stated upgrade path is more than can be said of much of what we connect.
The two database lines, and what each means for reading the data
Business One is one application on two engines, and for anyone reading the data they are not the same thing. The application, the modules and — the part that matters most — the table and field names are identical: a journal entry lives in OJDT and JDT1 on both lines. What changes is the engine, the dialect, and what analytical machinery arrives in the box.
| SAP Business One on Microsoft SQL Server | SAP Business One, version for SAP HANA | |
|---|---|---|
| Engine | Microsoft SQL Server 2019 or 2022, on Windows Server | SAP HANA 2.0 on certified hardware or cloud, under SUSE or Red Hat Linux |
| Query dialect | T-SQL, over ODBC or JDBC | SQLScript, over the HANA client |
| Analytical layer included | Query Manager, Crystal Reports, financial report templates | The same, plus published semantic-layer calculation views and pervasive analytics |
| Consequence for extraction | Familiar and inexpensive — any SQL practitioner reads it on day one | Faster on wide analytical reads, with SAP’s own definitions of the objects included |
Neither line succeeds the other. SAP keeps both current while weighting analytical innovation towards HANA. For a reporting layer the line changes the plumbing and almost nothing else: the schema is identical, the model above it is identical, the output is the same governed numbers. A technical decision, not a reporting one.
Who SAP Business One fits
Subsidiaries of groups that already run SAP. The most common way Business One arrives: the parent runs SAP, a new or acquired subsidiary is too small to carry that, and Business One is what SAP and its partners put in — one system, one partner, a localisation that already exists. Usually the right call, with a consequence: a well-run SAP system inside a group whose other entities are on something else.
Manufacturers and distributors in the lower mid-market. Production orders, bills of material, MRP, several warehouses, batch and serial tracking, landed cost. This is where Business One is strongest — the operational depth is real, and included rather than bolted on.
Companies that trade across borders early. Dozens of country localisations in one application, multi-currency throughout, and intercompany capability published by SAP itself — an unusual position at this size.
Slovak, Czech and Polish entities inside international groups. SAP localises all three markets directly: Slovak, Czech and Polish are SAP-shipped system languages, and the Slovak kontrolný výkaz DPH and Czech kontrolní hlášení are addressed in the localisation rather than in a third-party app. Two edges: Slovak eKasa is a partner and device matter, and a Polish user should confirm with their partner which route KSeF e-invoicing takes. Neither makes Business One the wrong system here — it makes the estate Business One plus a named set of compliance components, and a reporting layer has to know which.
Groups that grew sideways. Business One in the SAP-standardised subsidiary, something local in the entity acquired last year, a spreadsheet in the newest venture. Every choice was correct where it was made; what nobody owns is the view across them — the context in which Business One reaches us more often than any other.
What SAP Business One holds — and why it is good material
Before the reporting question, the asset. This is a disciplined system, and the discipline shows in the data.
Every posting lands in a double-entry structure that reconciles because the application makes it reconcile. Journal headers sit in OJDT, their lines in JDT1, joined on TransId; every JDT1 line points at an account code in OACT, the chart of accounts. Documents, inventory movements and payments generate their journals through the same path — the ledger is the same event, posted, not a separate assertion.
The analytical structure is real, and better than most systems at this size offer. You define up to five dimensions — SAP’s own examples are departments, branches, product lines and projects. Within each sit cost centres, the units that absorb cost or generate revenue; distribution rules split an amount across several cost centres by a defined ratio, so shared cost is allocated rather than dumped. A single journal line can be tagged across five independent analytical axes without one extra segment in the chart of accounts — cost centre structure for profitability analysis that already exists.
Extensibility is first-class and visible in the schema. User-defined fields are real columns with a U_ prefix; user-defined tables carry an @ prefix. The boundary between what SAP shipped and what this business added is explicit in the names, without documentation — a gift to anyone reading the data.
And here is the point worth making respectfully rather than as a complaint. The names are four-character codes — OJDT, JDT1, OACT, OCRD, OITM. O marks an object header, a numbered suffix marks the lines beneath it. The convention comes from a product that had to be compact, portable and fast across dozens of localisations, and it has served it well for over twenty years. It is also why nobody reads Business One data casually: the information is complete and the discipline is high, and what stands between it and a finance director — or an AI assistant — asking a plain question is a translation layer. Not a fix. A translation.
The data quality in a properly run Business One is usually good — a strong starting point. The quality of a reporting layer is bounded by what feeds it, and this feeds it well.
What sits outside SAP Business One’s scope
Business One is scoped to running one company completely and correctly. Three things sit outside that scope, and each boundary was drawn deliberately.
The view across companies, at transaction level. Business One holds one database per company — architectural, not a setting. Ten entities are ten databases sharing only SBO-COMMON. SAP addresses the group case with a published add-on, the intercompany integration solution, and it does real work: intercompany replication, local and foreign currency, a multi-level consolidation hierarchy. Two things define its edge: it consolidates into an additional Business One company — a reporting container rather than a place where group transactions live — and it federates Business One databases only, so a group with entities on other systems is outside what it was built to do, correctly. Capable for statutory consolidation in an all-Business One group; the wrong shape for a mixed estate.
The view across systems. Whether e-commerce revenue matches the ledger, or the payroll run matches headcount. Worth saying plainly: no ERP does this. Not Business One, not Business Central, not SAP S/4HANA — SAP builds two of those three and does not claim otherwise. Cross-system truth is a layer above every transaction system, which is the point we make at more length here .
The management view, held somewhere durable and shared. Business One’s reporting is more capable than its reputation suggests — Crystal Reports integrated properly, shared Query Manager queries, real financial report templates, published calculation views on HANA. All of it runs inside one company database, against the transactional tables, in four-character names, with the definitions stored where the transactions are. Exactly right for operational reporting; not a data model a dashboard or an AI assistant can query across a group. More on the distinction: business intelligence and reporting .
None of this is a reason to change system. It is a reason to add a layer.
How we elevate it
We connect SAP Business One on either database line, in single entities and in groups where it sits beside whatever the rest of the estate runs.
Getting the data out is the straightforward part; being precise about the route is most of the craft. Our default is a dedicated read-only database login: T-SQL over ODBC or JDBC on the SQL line, ideally against a replica; the HANA client on the HANA line, reading SAP’s calculation views where they answer the question and the base tables where they do not. Before design, we ask your SAP partner or licensing contact to confirm the read against your agreement’s terms — licence paper differs, and it is cheaper to confirm than to argue later. Where direct database access is not available — typically a partner-operated cloud landscape — the supported route is the Service Layer, with the SQLQueries endpoint doing the analytical work. Extraction runs incrementally, nightly or more often, nothing is written back, and users notice no difference in how Business One performs.
Then comes the Business One-specific work.
The four-character schema, translated once
OJDT becomes journal entries. JDT1 becomes journal lines. OACT becomes the chart of accounts, OCRD business partners, OITM items. We do that translation once, in a model, with the business meaning attached and versioned — no report, no analyst and no AI assistant ever has to know that a posting header is called OJDT again. Alongside it we map the statutory chart of accounts to a management structure: revenue by what you actually sell, cost by what you actually control, margin at the level you actually decide — with Business One’s U_ and @ conventions keeping the mapping unusually clean. Mapped once, owned by a named person, reviewed at each close. The design problem underneath: chart of accounts architecture
.
The five dimensions, cost centres and distribution rules, put to work
The dimension framework is the most under-used asset in most Business One installations, and repairing it is high-yield work. We flatten the dimensions and cost centres into the model as columns, so every posting carries its analytical tags natively, then audit how consistently they have been filled — which dimensions, on which accounts, since when, and where a distribution rule quietly stopped being maintained. Where history is thin we agree what gets enforced going forward; spreadsheet allocation logic becomes a versioned rule in the layer. Two details are worth planning for: an object called a profit centre in a pre-9.0 configuration is the same object now labelled Cost Center, and older Crystal reports will still say so; and distribution rules apportion by ratio, so the model has to reproduce the ratio rather than the result if allocated cost is to reconcile back to the journal.
One view across company databases, and across the estate the parent actually runs
Each Business One company database becomes one entity in a common model — beside another Business One company, a POHODA or Helios installation, a Business Central entity in the parent, an e-commerce platform or a payroll export, all producing the same standardised output. Group reporting in any currency with currency translation applied consistently, reconciliation across systems, intercompany elimination in the layer, and drill-down from a consolidated total back to the JDT1 line that produced it — the step a consolidation company inside the ERP cannot offer. This argument matters most here, because Business One so rarely arrives alone.
This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .
On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.
What becomes answerable
- Which customers are actually profitable, after delivery, service and allocated overhead — not just gross margin on the invoice?
- What is group EBITDA in one currency, when two entities sit in Business One and three sit on something else?
- What did that production run or project cost against quote, while it is still open?
- Why did overhead move this month, ranked by the cost lines that moved most — against budget and against last year?
- How much cash is tied up in stock that has not moved in six months, across every warehouse in every entity?
Every one of these is answered from data SAP Business One is already holding. The information was there. What was missing was the structure to ask.
What it takes, and what does not change
Connection in days. First reports in the first week. For a single-entity SAP Business One client, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.
What we need from you: an NDA, read-only access, and a conversation about what the numbers should mean.
What does not change: SAP Business One stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.
Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.
When the system underneath changes
Business One moves in both directions: it arrives to replace software a company has outgrown, and it is occasionally replaced in turn — by Business ByDesign or S/4HANA when a subsidiary outgrows the tier, or when a group standardises on the parent’s platform. A move between the two database lines is a smaller version of the same event.
Either way, because the governed layer sits above the ERP, only the connection changes. The data model, the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first can prove the new system’s numbers against the old from day one and keep their reporting history through the change — the group view holds steady while the systems underneath move one at a time.
This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.
How SAP Business One compares
SAP Business One is one of several capable systems in the estates we work in. Each has its place in the series .
| System | Vendor | Market | How it compares |
|---|---|---|---|
| POHODA | STORMWARE | CZ · SK | Accounting-led, deeply localised, often the local trading company’s system; its own article here |
| Helios | Asseco | CZ · SK | Mid-market ERP with production and project depth, strong local fit |
| Business Central | Microsoft | Global | The other system mid-market groups standardise on; its row is in the series matrix |
| NetSuite | Oracle | Global | Cloud-native; consolidates subsidiaries inside the product rather than through an add-on |
| SAP S/4HANA | SAP | Global | Where Business One entities go when they outgrow the tier — a different product and data model, not a larger Business One |
From a data-layer perspective the choice matters less than it appears. Each of these becomes an entity in the same governed model, which means the ERP decision can be made on operational fit rather than on reporting fear. The full matrix — including the Polish stack — is on the series hub .
Frequently asked questions
Do we need to replace SAP Business One to get proper management reporting? No, and we would usually advise against it. Keep SAP Business One for what it does well — statutory correctness, VAT, clean transaction capture, operational control — and build the reporting layer above it. Replacing a working ERP to solve a reporting problem is an expensive way to solve the wrong problem.
Is Onetribe a replacement for SAP Business One? No. SAP Business One remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change ERP later, the reporting layer stays.
Is SAP Business One a full ERP, or SAP’s small-business product? Both — there is no contradiction. It is a complete ERP — ledger, purchasing, sales, stock, production, MRP, service — and the entry line of SAP’s range, on its own code base rather than a reduced S/4HANA. Companies leave it because they have outgrown the tier, not because it stopped working.
What database does SAP Business One use, and can we read it directly? Two lines: SAP Business One on Microsoft SQL Server, and SAP Business One, version for SAP HANA on SAP HANA 2.0. The tables and field names are the same on both; the dialect is T-SQL on one and SQLScript on the other. We read through a dedicated read-only database login — and before design, we ask your SAP partner or licensing contact to confirm the read against your agreement’s terms; licence paper differs, and it is cheaper to confirm than to argue later. One database per company, so a group is several databases rather than one database with a company column.
Can SAP Business One connect to Power BI? Yes, by three routes: the Microsoft SQL Server connector reads the SQL line, the SAP HANA connector reads the HANA line, and OData reaches the Service Layer — all general-purpose paths, as SAP ships no Business One-specific connector. The durable pattern is Power BI on a governed model rather than on the ERP: refreshes land on your live transactional system, and one report per database does not become a group report by being duplicated.
Can SAP Business One consolidate several companies? Yes, through SAP’s intercompany integration solution: intercompany replication, multi-currency, a multi-level consolidation hierarchy. Two limits — it consolidates into an additional Business One company holding a summary rather than drillable transactions, and it federates Business One databases only. Interrogating a group number across a mixed estate is the most common reason multi-entity Business One users come to us.
Does SAP Business One have an API?
Yes, several. The Service Layer is REST and JSON over OData v4, with an SQLQueries endpoint; the DI API and DI Server give business-object access, and the integration framework, B1if, is included with the licence. The same routes bring the surrounding systems into the layer — payroll among them, which sits outside Business One.
Is SAP’s own reporting enough? For a single company, often yes — and worth using properly before adding anything. Crystal Reports, Query Manager, the report templates and the HANA calculation views give a credible self-service layer, all inside one company database with the definitions stored where the transactions are. Across companies, across systems, and anywhere a definition needs to be governed and shared, something has to sit above it — but if Business One is your only system and one company is your whole business, start there.
Official SAP Business One resources
- SAP Business One product overview — SAP
- SAP Business One documentation — SAP Help Portal
- Maintenance and release family for SAP Business One — SAP Support Portal
- Working with cost centres and distribution rules — SAP Help Portal
- SAP Business One Service Layer API reference — SAP Help Portal
- Intercompany integration solution for SAP Business One, user guide — SAP Help Portal
Onetribe is not an SAP partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.
Next steps
- Every source system we connect — the series hub, with the full matrix
- How we consolidate any combination of ERPs — group reporting
- Why your ERP doesn’t govern your data — the cross-system layer, in detail
- Discuss your SAP Business One estate — free assessment