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.

Your ERP remains the system of record for financial actuals. Sync or post the relevant accounting entries from external systems into your ERP first. These include spend tools such as Ramp, billing and subscription-management software, accounts payable and receivable tools, procurement systems, and inventory subledgers. PipeLedger works from those ERP records rather than adding a separate feed of the same activity. Activity not yet recorded in the ERP is not included in those financial actuals.

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.

Read about the financial ontology and Entity Context for the business definitions, legal and tax profiles, and recorded ownership relationships that support financial analysis.

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.

PipeLedger uses SQL checks to test that financial meaning survives transformation. Depending on the source and datasets being built, these checks cover:

• Balanced accounting: check that debits and credits balance for supported source transactions and Trial Balances, within defined accounting tolerances.
• Source-scoped joins: test relevant join keys for uniqueness within each source connection and require each ledger account to resolve to exactly one classification.
• Preserved ledger activity: compare row counts and reporting-amount totals before and after customer, vendor, and project enrichment to detect lost or duplicated activity.
• Reconciled outputs: match Trial Balance debits, credits, net movements, and transaction counts to the ledger at account, period, entity, book, segment, and project scope. Test indirect cash flow components against ledger income and working-capital balance movements.
• Build and schema contracts: check required fields, confirm each dataset was built in the current run, and verify that delivered columns, their order, and descriptions match the declared schema.

Separate release tests compare model outputs with fixed expected results for accounting edge cases, including fiscal-year close reversals.

Certification records applicable check outcomes and current-run build and schema evidence for each output. A blocking failure prevents the affected output from being published. Consumers continue to use the previous approved snapshot, where one exists.

Controllers review account classifications and operating, investing, and financing cash flow treatment, with governed account and eligible transaction overrides. Review decisions retain audit evidence. Applicable authorized approval is required before publication makes a snapshot available to consumers.

These controls validate the pipeline output. Your team remains responsible for source-book completeness and accounting decisions; pipeline certification does not replace source reconciliation or an independent audit.

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.