Run Crystal-Reports-style outputs, BI dashboards, and ad-hoc analytics against archived B1 data on cloud object storage. SQL, REST, Power BI, Tableau, Excel via ODBC, BI Publisher template reuse — no live B1 needed.
After B1 decommissioning, the data is preserved but the question is: can users still produce reports against it? Without archive reporting, the answer is no — and that's where the unprepared SMB discovers a problem.
Most SAP Business One migration projects scope the data archive (move OINV, OPCH, OJDT, OCRD, OITM and supporting tables to long-term storage) but then under-scope the reporting layer on top of that archive. The thinking is 'we'll move the data, and if anyone needs a report, they can run SQL'. This works for the small subset of SQL-fluent users who can write queries against archive tables — but it fails the majority of business users who consume reports rather than write them.
The first time a customer requests a copy of their 2019 invoice and the customer-service team has no way to produce one is when the gap becomes obvious. The first time the year-end auditor asks for a comparative trial balance pulling 2019 vs 2020 vs 2021 in report format and the finance team has nothing but raw SQL is when the gap becomes painful. The first time a tax-authority examination demands report-grade AR aging snapshots as of various historical dates and the SMB has to scramble to produce them is when the gap becomes expensive.
SAP Business One archive reporting is the reporting layer that prevents all of those scenarios. The same Crystal-Reports-style outputs (invoices, statements, POs, deliveries, remittances) that B1 originally produced are reproducible against the archive — using the BI Publisher templates that were already built during the report-migration workstream. The same analytical dashboards (sales by region, AR aging, inventory turns) that were rebuilt as OTBI can additionally point at archive data for historical-period reporting. Power BI, Tableau, Excel via ODBC all connect to the archive natively. The reporting layer survives B1 decommissioning.
Seven BI tools natively supported against the archive. Each tool has its own connector, its own optimal use case, and its own pre-built starter content.
Direct connection via Parquet connector or SQL endpoint. Pre-built dashboards: sales analysis, AR/AP aging, inventory turns, customer 360. Refresh-on-schedule for ongoing executive dashboards spanning B1 and Fusion.
Connection via Tableau's Parquet driver or SQL endpoint. Pre-built workbooks for analytical use cases. Tableau Server publishing supported for distribution to non-Tableau-licensed consumers via web view.
Standard ODBC connection for finance teams. Pre-built workbook templates: trial balance, GL detail, AR aging snapshot, AP aging, inventory valuation. Named ranges, refresh-on-open. The dominant accountant pattern.
BI Publisher templates from the report-migration workstream repointed at the archive. Historical invoice/PO/statement/delivery/remittance reprints in original layout. PDF output identical to original B1 print.
Fusion OTBI configured with archive as external data source. Cross-period analytics combining live Fusion data with archive history. Pre-built subject areas for sales, finance, procurement, inventory.
Programmatic JSON access for custom consumers (customer portals, partner integrations). Direct SQL via DBeaver, DataGrip, SSMS, Toad for SQL-fluent power users. Same table shapes as B1 SQL — many queries work unmodified.
Six steps from archive structure design through go-live reporting. Most of this runs concurrent to the data-archive workstream — reporting layer doesn't add to critical path.
Inventory the reports that need to keep working post-B1: customer-facing document reprints, finance trial-balance/aging reports, auditor pack, tax-authority pack, executive dashboards. Each gets classified by frequency, audience, tool, and pre-built availability.
Partition the Parquet archive by fiscal year + month + entity for optimal query performance. The partition strategy is driven by reporting query patterns — analytics querying time ranges benefits from time partitioning, multi-entity scenarios benefit from entity partitioning.
Configure the archive's SQL endpoint with appropriate connection drivers, schema visibility (the OINV/OPCH/OJDT/OCRD/OITM table shapes that BI tools expect), security policies, and connection pooling. Test connectivity from each BI tool target.
Take the BI Publisher templates built during report migration (invoice, PO, statement, delivery, remittance) and create archive-pointing variants. Test historical document reprint against known reference outputs.
Build the starter dashboard library: Power BI dashboards for executive views, Tableau workbooks for analyst views, Excel workbook templates for finance team. Each pre-populated with the standard SMB reporting layouts.
Onboard each user population to the appropriate archive reporting interface. Customer-service team trained on customer 360 + document reprint. Finance team trained on Excel ODBC + BI Publisher historical reprint. Executives trained on cross-period OTBI dashboards. Auditors and tax authorities onboarded as part of their respective engagement processes.
The reporting library that ships with archive reporting setup. Covers 80%+ of typical SMB historical reporting needs out of the box — extensible for the rest.
Reprint any historical invoice, AR statement, PO, delivery note, vendor remittance, credit memo from the BI Publisher template library with archive data binding. PDF output identical to original B1 print. Self-service for customer service and AP/AR teams.
Trial balance, GL detail, AR aging snapshot, AP aging snapshot, inventory valuation as of any historical date. Standard format used by accountants, auditors, tax advisors. Excel and PDF outputs. Period-comparison versions.
Single-screen customer view: contact, complete invoice/delivery/payment/credit-memo/return history. Vendor mirror. Sub-second response. Used by customer-service and AP/AR for dispute resolution.
Sales by customer/product/region across pre- and post-cutover years. AR/AP trends. Inventory turnover history. Vendor performance multi-year. Combines archive history with live Fusion data via OTBI.
Jurisdiction-specific pre-built tax-authority extracts: UK MTD VAT format, German UStVA, French TVA, Italian LIPE, US state-level sales tax. Time-scoped, audit-logged, signed output suitable for examiner submission.
Auditor-grade comparative reports, transaction-level drill-downs, SOX-style access logs, litigation-hold output formatted for legal-discovery requirements. Built for forensic and statutory engagements.
SAP Business One archive reporting is the ability to run Crystal-Reports-style reports, BI dashboards, and ad-hoc analytical queries against archived B1 data — data that lives in Parquet on cloud object storage rather than in a live B1 instance. The difference from live B1 reporting is structural: there's no SQL Server or HANA database underneath, no active B1 application server, no Crystal Reports runtime licence required. Instead, the archive exposes the same OINV/OPCH/OJDT/OCRD/OITM table shapes via SQL (JDBC/ODBC), REST API, and BI tool connectivity (Power BI, Tableau, Excel via ODBC). Reports written against live B1 SQL can in many cases be lifted-and-shifted to run against the archive with minimal change. The benefit: post-migration, the SMB can decommission B1 entirely while preserving full reporting capability against the historical data.
Six reasons drive the SAP Business One archive reporting requirement. (1) Tax authority audits — IRS, HMRC, Finanzamt, DGFiP examiners look back 6–10 years and need report-grade output, not just raw table extracts. (2) Statutory reporting amendments — year-end statements that reference prior B1 periods, occasional restatements that span B1 and post-B1. (3) Customer/supplier dispute resolution — historical AR/AP detail reports needed for occasional disputes. (4) Internal trend analysis — multi-year sales trends, customer lifetime value analysis, vendor performance over time that crosses the B1/Fusion boundary. (5) Litigation hold — when subpoenas demand report-grade output of historical B1 data. (6) Internal forensic investigations — investigating historical transactions with report-grade evidence output. Each requires actual reports, not raw SQL — which is what SAP Business One archive reporting provides.
The archive is designed for multi-tool access. (1) Power BI — direct connection via the Parquet/cloud-storage connector or via the SQL endpoint. Native Power BI dashboards refresh against archive data. (2) Tableau — similar via Tableau's Parquet connector or SQL endpoint. (3) Excel via ODBC — finance users connect Excel to the archive's ODBC endpoint, pull data into named ranges, refresh on open. The most common pattern for SMB accountants. (4) BI Publisher — the same BI Publisher templates built in the Fusion migration can be repointed at the archive for historical-period running. (5) OTBI — Fusion's OTBI can query the archive as an external data source for cross-period analytics. (6) Custom REST API consumers — any tool that speaks REST can pull JSON-formatted archive data. (7) SQL clients — DBeaver, DataGrip, SSMS, Toad all connect via JDBC/ODBC.
Yes — and this is one of the highest-stakes archive reporting capabilities. The Crystal Reports templates that B1 used to print invoices, AR statements, POs, deliveries, vendor remittances are migrated to BI Publisher during the report-migration workstream (covered separately) — but those same BI Publisher templates can be pointed at the archive instead of the live Fusion environment to reprint historical documents. This means: a customer requests a copy of their 2019 invoice → the archive query reconstructs the OINV/INV1 detail → the BI Publisher template renders → output is a PDF that looks identical to what B1 originally printed. Same for re-rendering historical AR statements, vendor remittances, delivery notes, purchase orders. The 'I need a copy of an old document' workflow that previously required B1 access is now archive-only.
Performance is generally better than live B1 reporting for analytical workloads, comparable for transactional drill-downs. The reason: archive storage uses columnar Parquet format optimised for analytical queries, with partitioning by fiscal year + month + entity. A 'sales by region for the last 5 years' query that took 30+ seconds in B1 (because B1's row-store database wasn't columnar-optimised) returns in 2–5 seconds against the archive. Transactional queries (customer 360, invoice lookup) are sub-second in both because the archive maintains appropriate indexing. Bulk extract performance (give me all 2019 OINV records) is significantly faster against the archive because Parquet's columnar format and partition pruning make full-period reads efficient.
The archive layer applies the same role-based access controls as live B1 reporting plus additional protections. Authentication is via SSO (SAML/OIDC) for internal users, federated for external auditors with SOC2-compliant identity providers, time-limited tokens for tax authorities. Authorisation is role-based with data-domain scoping (e.g. external accountant gets AR/AP but not payroll, tax examiner gets the fiscal years under examination only). PII can be masked or unmasked based on role (e.g. customer-service sees masked credit card last-4, audit examiner sees unmasked). Every query is logged with user/timestamp/query-text/rows-returned. Logs are retained for 7+ years for audit purposes. Encryption is at-rest (AES-256 on the object storage layer) and in-transit (TLS 1.3). VPC-private endpoints available for SMBs that want network-level isolation.
Yes — multi-company B1 archive reporting is a common requirement, especially where the SMB grew through acquisition and ended up with multiple B1 company databases (each acquired entity having had its own B1). The archive stores each B1 company database as a separately partitioned dataset, with its own complete OACT/OJDT/OCRD/OITM tables. Archive reporting can query a single company, a subset, or all companies depending on role and use case. Cross-company consolidated reports (e.g. consolidated sales across all acquired entities) are built as virtual views with appropriate currency translation and intercompany elimination. Per-company access scoping is supported (e.g. an audit examining one acquired entity gets archive access scoped to that entity only, not the other acquired entities — useful for limited-scope examinations).
Archive retention is policy-driven and configurable per data domain and per jurisdiction. Typical retention windows: 6 years for HMRC, 7 years for US IRS, 10 years for German GoBD and Italian SDI, 10 years for French CGI, 5–10 years for general SOX-related retention. Some SMBs choose to retain beyond the regulatory minimum as a matter of internal policy (e.g. indefinite retention for sales and customer history for marketing/CRM purposes). Within the retention window, SAP Business One archive reporting works exactly the same in year 1 as in year 10 — same SQL endpoints, same BI tool connectivity, same BI Publisher templates, same sub-second response. Storage cost scales with data volume (pennies per GB-month on cloud object storage) — economically minimal even at long retention. Beyond the retention window, data is securely destroyed per the configured policy with a destruction-evidence log retained for audit purposes.
Crystal-Reports-style historical document reprint, Power BI / Tableau / Excel analytics, BI Publisher templates, cross-period OTBI dashboards, tax-authority and audit packs — all against archived B1 data on Parquet. No live B1 needed.