How your ERP data becomes a published financial dataset

Connects QuickBooks Online and NetSuite today, with Dynamics 365 and Rillet in development. Each connector keeps the source company's connection and accounting configuration together; your pipeline selects the financial data products to prepare.

Connector configuration maintains an overview of your ERP environment: project modules, class and location tracking, account numbers, inventory tracking and valuation methods, time tracking, and multi-currency settings. It combines settings discovered from the source with accounting choices you confirm, so the pipeline can interpret your data in the context of how your business uses the system.

Transactions retain their Legal Entity context: the connected company in QuickBooks, or the relevant subsidiary in NetSuite. That context follows each financial line into the warehouse, keeping the books identifiable when you connect multiple companies or ERP systems.

PipeLedger uses BigQuery for analytical storage and computation. Extracted source data passes through deterministic dbt models that normalize account information, dimensions, periods, and currency context according to your configuration.

Normalization covers financial meaning as well as column names. QuickBooks documents are reconstructed into supported debit and credit activity; NetSuite financial processing starts from posted accounting impact in the primary book. Both feed a common model with source references, account classifications, and reporting context.

• General Ledger reconstruction: turn QuickBooks posting documents and NetSuite primary-book accounting lines into a common debit-and-credit model, preserving the source records behind each posting.
• Chart of accounts mapping: retain native account names and numbers while applying a shared financial taxonomy and GAAP-aligned categories, with your approved account classifications.
• Customer, supplier, and project relationships: keep these roles distinct, preserve their hierarchies, and carry the right counterparty and project context onto financial activity.
• Business dimensions: normalize classes, departments, locations, and custom dimensions into business lines, geographic segments, and functional segments according to your approved mappings.
• Multi-entity reporting: bring connected companies into one financial warehouse with consistent reporting vocabulary while retaining each line's Legal Entity and source connection.
• Currency and fiscal periods: preserve source amounts and currency context, align activity with your fiscal calendar, and distinguish period movements from point-in-time balances.
• Cash flow classification: apply operating, investing, and financing treatment with governed account rules and reviewed exceptions, preparing the components used in cash flow reporting.
• Reporting-ready datasets: prepare General Ledger Lines, Trial Balance, financial-statement outputs, and your configured project and unit datasets, with source references for tracing results back to their supporting records.

The QuickBooks guide and NetSuite guide explain the source-specific work behind this common financial model.

Each stage has a defined role. Internal source and transformation datasets support processing; purpose-built financial datasets, called marts, are prepared for governed delivery. Connecting an application does not grant it access to the internal warehouse layers.

An AI model can interpret delivered financial information. It does not calculate or rewrite the authoritative dbt values.

PipeLedger extracts accounting history as far back as records are available through your source APIs. Choose the history you want to bring into the warehouse; a refresh lookback window does not limit the age of your initial historical import.

Manual backfill is available on request, including imports from QuickBooks Desktop exports. We can help bring older records and opening balances into your reporting history alongside ongoing extraction. Desktop imports do not require a live QuickBooks Desktop connector.

Account classification review highlights ambiguous mappings and prioritizes findings using review materiality. Controllers review account taxonomy and operating, investing, and financing cash flow classification, with governed account and eligible transaction overrides. Review decisions retain audit evidence.

The pipeline evaluates applicable financial-integrity and schema controls before publication. These include accounting balance checks and checks appropriate to each dataset's grain. A blocking failure prevents the affected delivery from being published.

Eligible marts require the applicable authorized approval. Publication makes an approved snapshot available to consumers. Completing an extraction, materializing a table, and publishing usable data are different events; verify publication status before relying on a new run's output.

Certification describes the checks and evidence for the pipeline output. It does not certify your accounting policies or provide an independent audit of the underlying transactions.

You control when your data refreshes. Run a refresh as often as you need from the PipeLedger app or your terminal using the CLI, and manage scheduled batches to suit your reporting routine.

• Routine refresh: pick up recent changes for day-to-day reporting.
• Deeper refresh: revisit the last 90 days or fiscal year when you want to include backdated changes.
• Full refresh: reload source history for an initial import or a deliberate rebuild.
• Transform only: rebuild financial outputs from data already in PipeLedger, for example after changing classifications, without extracting again.

Choose which data products to build and whether results go to Data Review or use authorized automatic approval. Reports and connected tools use the newly published data once the run and approval finish. Processing usage follows your plan's usage terms.

See pipeline run controls in the PipeLedger Tool Guide for the available stages, refresh depths, and publication options.

MCP, REST, and CLI enforce the caller's permitted capabilities and data access. Dimension scope limits which rows contribute; account confidentiality controls the detail that can be returned. Identity privacy and explicit identity grants determine whether permitted identifying values appear as stable tokens through identity tokenization (pseudonymization) or original values.

• Standard keeps full transaction columns, subject to the applicable privacy and delivery policy.
• Restricted removes identifying columns while retaining the financial line.
• Highly Restricted removes transaction grain and returns only ledger totals with the minimum accounting context needed to interpret them. Returned totals do not expose underlying identities, scope metadata, or transaction counts.

Memo prohibitions cannot be overridden by an identity grant. A connected application's response may therefore contain fewer columns, masked identities, or less detail than an authorized administrator's view. The exact result follows the caller's clearance and current policy.

Review account confidentiality and identity privacy and the MCP permission boundary before connecting a consumer.

• Which source companies, historical periods, and dimensions must be available?
• Which financial datasets and statements does the team need?
• How recent must published data be for the decision it supports?
• Who reviews accounting configuration and approves eligible outputs?
• Which identities and transaction details may each consumer receive?

Use these answers to assess plans and usage or discuss a specific requirement with support. For an ownership comparison, read the build-or-buy guide.