Skip to main content
DBVault

DBVault: Enterprise-Level ERP and Business Data Archival and Reporting Platform

When an ERP is retired, merged, migrated or simply switched off, the records it held are still needed: by auditors, by tax authorities, by the finance team, by whoever is asked about an old transaction. DBVault is where that history lives afterwards. It is our cloud-hosted platform for ERP and business data archival and reporting: a read-only, relational archive your finance team can search, scope access to and produce financial statements from, without the system that created it. It is delivered today as DBVault for NetSuite and for SAP archives, and every archive gets the same platform underneath.

One platform, a flavour per system

DBVault is the platform; a flavour is how it is delivered for a particular ERP. Each archive holds that system's records in their own schema, with the relationships and the general-ledger detail the source kept, and the same search, access controls and reporting sit in front of every one of them.

An archive atrium with galleries of bound ledgers on every level: one platform holding the history of more than one system

DBVault for NetSuite

The deepest flavour, and the one most of this site describes: transactions with their sublists, the GL impact of each one, entities, the chart of accounts, custom records and File Cabinet attachments. It is fed by AcroXtract when an account is retired, or by AcroBackup for NetSuite while it stays live. What it holds, report by report, is on the DBVault for NetSuite page.

SAP archives

Delivered through AcroXtract for SAP: finance, asset accounting, controlling objects and open receivable and payable items, with the customer's own custom tables, held per company code and fiscal year and reconciled to the books before sign-off. Everything the platform gives a NetSuite archive it gives an SAP archive.

Other ERP and business systems

Oracle NetSuite is where most of our engagements have been and where our tooling runs deepest. Another system is named on this site only once an archive of it has been delivered. The platform itself is source-agnostic: an archive is built from an ERP extraction or from business data loaded as CSV into archive objects, at scale. If yours is not named, describe it during scoping; the answer depends on how its data can be read and verified, which is the service side of the work rather than the platform.

What an archive has to do after the system is gone

Possession is not usability. A database copy in a folder satisfies a storage policy and fails the first real question. An archive is judged by what people can reliably do with it later, and the platform is built around five things.

1 · Hold the records as records

Each archive is a relational database, not a set of files. A transaction still resolves to its entity, its lines, its posting and its attachments, and custom records come across as named record types of their own.

2 · Keep the ledger detail

The general-ledger impact of every transaction is held: the accounts, the subsidiaries or company codes, the periods and the accounting books it posted to. That is what lets a trial balance for a closed year come from the archive rather than from a spreadsheet.

3 · Let finance find things

Search across the whole archive, with filters by date, transaction type, subsidiary and custom field, so a finance user finds a record the way they did in the source system. Each record opens with its sublists and attachments in place.

4 · Produce the statements

Financial statements run inside the platform against the archived ledger: trial balance, balance sheet, income statement, general ledger, account activity and transaction detail, with management, multi-currency and audit reports beside them. No source-system licence, no export first.

5 · Prove who saw what

Access is read-only, assigned through named roles and restriction profiles, and every login and download is logged, so a question about the archive has an answer as well as the archive itself.

A reading room of bound ledgers with one lamp lit: the records of a retired system, still readable when someone asks

What every archive keeps

Relationships between records, in the archive's own schema.

GL impact per transaction, by entity, period and accounting book.

Attachments linked to their records.

Custom records and custom fields alongside the standard types.

Records read-only once finalised, with logins and downloads logged.

Snapshots and CSV exports, so the data can leave.

More than one archive, one set of rules

One platform can hold more than one archive, so a group that ran several instances, or is retiring more than one system, keeps its history in one place under one set of access rules. Each archive keeps its own schema and the relationships between its records.

Financial reporting on archived data

This is what turns stored records into something a finance team can use. Most retention products give you records back. DBVault also gives you the statements built from them, produced inside the platform against the archived ledger, and the underlying records stay reachable from each figure, so a reviewer can move from a balance to the transactions behind it without leaving the platform.

Financial statements

Cumulative and consolidated trial balance, period activity balance, balance sheet, income statement, general ledger, account activity, chart of accounts and transaction detail: the reports a close, an audit or a statutory filing is normally built from.

Management and multi-currency

Profit and loss by department, class, location and subsidiary; revenue by customer and expenses by vendor; trial balance by currency and FX analysis, so a group can still reconcile a prior period the way it was originally reported.

Audit and compliance

Transaction journal, period comparison, account type summary and the reversals report, for the questions that arrive from outside the business, where showing the working matters as much as the number.

Multi-Book, and the reports you rely on

Multi-Book accounting is supported. A custom report built in the source system is not reproduced automatically; the reports you rely on are confirmed during scoping and tested during your validation period. Access to the statements follows the same roles as the rest of the archive, so a read-only reviewer can be given the reports without the ability to export everything.

Who gets in, and what they can see

The second question every security review asks of an archive is who can see what, and whether you can prove who saw it. The answer is a mechanism, administered by you.

Roles and named restriction profiles

Administrator and read-only viewer roles. A viewer's access is restricted by archive, record type, File Cabinet folder and subsidiary, each as an allow list or a deny list, through a named profile you can reuse; the product's own example is an auditor profile. Archives outside the profile are not shown.

Files reached only through records

Direct browsing of the document store can be switched off for a profile, so a file is reachable only as an attachment on a record the person may already see. Someone given access to look up invoices cannot wander the archive of documents.

Logged, and yours to administer

Login events and download history are kept inside the platform. Your administrator invites users, assigns profiles and removes access when an engagement ends; sign-in uses multi-factor authentication, with single sign-on available.

What this does not do

Restrictions apply to viewer roles; administrators cannot be restricted.

A profile does not limit by date; a viewer filters what they can see by period.

It does not load data into a successor ERP or back into the source system; the archive is exported as CSV or taken as a MySQL database for the team doing a load.

It is cloud-hosted only; there is no on-premises installation.

How data gets in: the services that feed the platform

DBVault holds and serves. The extraction, the verification and the scheduled capture are services, and they are the part of an engagement that depends on the source system.

A trial balance for a closed year on a desk, produced from the archive after the system that recorded it was switched off

AcroXtract, for a system being retired

A one-time extraction of the records, their relationships and the ledger detail, compared against the source at the database level, then worked by your own team during a validation period before sign-off. For NetSuite, AcroXtract; for SAP, AcroXtract for SAP.

AcroFile, for the documents

The NetSuite File Cabinet, extracted with its folder structure and each file's link to its record, so an attachment opens from the transaction it supports. AcroFile describes it.

AcroBackup for NetSuite, for a live account

Where the account is staying in production, AcroBackup for NetSuite, our continuous backup service, captures what changed each day into the same platform, so the copy is ready for record-level recovery without waiting for a retirement.

Validation before sign-off

Every archive is delivered with a validation period. Your team raises anything that looks wrong as a ticket inside the archive, and sign-off happens only after those are cleared. From then on DBVault runs as a managed service.

Hosting, security and the commercial shape

On Amazon Web Services, encrypted in transit and at rest, with network isolation; where residency is a requirement, an archive can be provisioned in a nominated region. Blueacrobat is ISO/IEC 27001:2022 certified and SOC 2 Type II audited, and the controls are published in our Trust Centre.

Hosting is an annual subscription, sized on the volume of data held, the size of the document content and the number of users who need access. Those figures come from a short sizing exercise, and a quote follows from it; there is no source-system licence to renew and no per-report charge. How that compares with keeping an account open only to be read is set out on the caretaker licence cost page.

The data stays yours. Records can be exported to CSV and an archive can be taken as a MySQL database, so keeping the history does not depend on the subscription continuing.

Questions asked about the platform

Is DBVault only for NetSuite?

No. DBVault is the platform for ERP and business data archival and reporting; DBVault for NetSuite is its NetSuite flavour and the one most of this site describes, because Oracle NetSuite is where most of our engagements have been and where our tooling runs deepest. The same platform hosts SAP archives delivered through AcroXtract for SAP. If your system is not named, describe it during scoping; the answer depends on how its data can be read.

What is the difference between DBVault and AcroXtract?

DBVault is the platform; AcroXtract is the service. AcroXtract extracts your data out of a system that is being retired, verifies it against the source and builds it into a permanent read-only archive. DBVault is where that archive lives afterwards and how your team reaches it: search, permissions, exports and financial reporting. The platform also hosts the output of AcroBackup for NetSuite, the continuous backup service, for accounts that stay live.

Can data be changed once it is in the archive?

No. The archive is held read-only once it is finalised, and every login and download is logged. That is what makes it worth producing a statement from: the figures cannot have been edited after the fact, by us or by anyone at your organisation.

Can we get the data out again?

Yes. Records can be exported to CSV, and the archive can be taken as a MySQL database. There is no direct API for feeding a downstream migration, so where data is being moved into another system it is handed over in those formats for the team performing the load.

Where is it hosted, and can we run it ourselves?

On Amazon Web Services, encrypted in transit and at rest, and it can be provisioned in a nominated region where data residency is a requirement. The platform is cloud-only, with no on-premises installation; the archived database can still be delivered to you as a MySQL copy to hold on your own infrastructure. The controls are on the Trust Centre.

Can one platform hold archives from more than one system?

Yes. One platform can hold more than one archive, so a group that ran several instances, or is retiring more than one system, keeps its history in one place under one set of access rules. Each archive keeps its own schema and the relationships between its records.

How is it priced?

As an annual subscription, sized on the volume of data held, the size of the document content and the number of users who need access. Those figures come from a short sizing exercise, and a quote follows from it. How that compares with keeping a read-only account is set out on the caretaker licence cost page.

See the archive answer a real question

Tell us which system holds the history and who will need it afterwards. We will show DBVault answering a real question against data like yours, reports included, and set out what it would take to get your archive onto the platform.

Thank you for your inquiry.

One of our representatives will be happy to get back to you within one business day.
Oops! Something went wrong while submitting the form.
SOC 2 Type II badge