PipeLedger provides governed financial context from enterprise resource planning systems to authorized people, applications, and AI agents. This overview explains the current design of PipeLedger's financial-data, AI-governance, access-control, publication, audit, and security features.
This page is informational. It is not an audit report, certification, service-level agreement, security addendum, or warranty and is not incorporated into the PipeLedger Subscription Agreement unless an executed agreement expressly states otherwise. Binding commitments appear in the applicable Subscription Agreement, Order Form, Data Processing Addendum, Security Addendum, or SLA.
1. Governance model
PipeLedger is designed as a governed transformation and delivery layer between a customer's source systems and downstream users or applications. The architecture separates:
- source acquisition;
- deterministic transformation and enrichment;
- validation and publication;
- authorization and disclosure policy; and
- governed delivery and evidence.
The controls described below depend on customer configuration, role assignments, source-system behavior, credential management, supported delivery surfaces, service availability, and documented product limitations. They reduce risk but do not eliminate all risk of unauthorized access, disclosure, configuration error, service defect, source-data error, or human error.
2. Source acquisition and ERP boundaries
PipeLedger connects to third-party ERP systems selected and authorized by the customer. Each connection is subject to the applicable ERP provider's terms and technical requirements.
PipeLedger's standard connector workflows are designed to retrieve configured source records without writing PipeLedger classifications, enrichments, journal entries, or accounting changes back to the source ERP. The provider scopes available to a connector may be broader than the operations used by PipeLedger, and providers may change their APIs, terms, schemas, or availability.
Hosted processing may preserve source-faithful records in protected ingestion and transformation layers where needed for deterministic processing, support, and reconciliation. Governed delivery applies separate authorization, identity, memo, and account-confidentiality rules before supported data is returned.
3. Deterministic financial transformation
Under the current documented transformation architecture, authoritative numeric transformations are performed through deterministic code and tested configuration rather than LLM-generated calculations. These transformations can normalize source records across ERP systems and legal entities and produce governed financial datasets such as ledger movements, trial balances, financial positions, report structures, and catalog-defined metrics.
Deterministic processing does not guarantee that source data, mappings, classifications, configurations, accounting policies, or resulting outputs are accurate or complete. Large language models and connected agents may generate narratives, explanations, classifications, queries, or conclusions that are incomplete or inaccurate and require qualified human review.
4. Publication and approval
After transformation and validation, an eligible governed dataset may require an approval before publication. Approval can be recorded by an authorized user or by a credential with expressly granted auto-approval permission. Unapproved data is not intended to be available through supported governed delivery surfaces that require publication.
Publication creates a controlled, versioned data state for supported downstream delivery. It does not independently verify the commercial substance of transactions, detect all errors or fraud, determine compliance with GAAP or IFRS, or replace the customer's accounting close, internal controls, or professional review.
Governance status is not professional certification
Approval, validation, publication, certification-status labels, provenance, reconciliation checks, audit records, and other governance features reflect technical or workflow states within PipeLedger. They do not constitute an audit opinion, assurance engagement, accounting certification, legal-compliance determination, or representation that Customer Data is accurate, complete, free from fraud, compliant with an accounting framework, or suitable for a statutory filing.
An approval recorded through auto-approval does not necessarily reflect human review. Customers remain responsible for independently validating outputs and maintaining their own books, records, internal controls, approvals, filings, and professional review.
5. Organization and dimension scope
Customer storage and access controls are scoped by organization to support tenant separation. Legal entities are governed reporting and authorization dimensions within an organization; they are not separate customer tenants unless the applicable agreement expressly provides otherwise.
Within an organization, authorization policies can limit which legal entities, departments, locations, classes, projects, and other supported dimensions may contribute to a response. Data scope and identity visibility are separate controls: permission to receive a row does not necessarily grant permission to receive every identity or field associated with that row.
6. Memo controls
Customers can configure whether general-ledger memo content is available for governed delivery. When memo sharing is prohibited, the Service is designed to omit or mask memo content across supported governed delivery surfaces, including supported live-query modes. Ordinary downstream identity permissions and credential settings do not override the configured memo policy.
This control applies to supported PipeLedger governed delivery. It does not remove a memo from the source ERP, historical exports, third-party systems, or other copies outside the governed delivery path.
7. Identity privacy and tokenization
Customer, vendor, employee, and project identities can be replaced with organization-scoped tokens or omitted from supported governed delivery. An applicable identity grant can reveal approved original values without expanding the rows otherwise within scope.
Within the supported semantic-layer scope, PipeLedger is designed to use a consistent token for the same governed identity across supported dimensions, statements, metrics, and delivery surfaces. This architecture reduces the need for downstream layers to process original identity values.
Within ordinary governed delivery, access to original identity values requires an applicable identity grant or authorized administrative process. PipeLedger may also process source values where reasonably necessary for deterministic transformation, reconciliation, security, support, legal compliance, or service operation, subject to applicable controls.
Tokenization reduces direct exposure but is not anonymization. A stable token may remain Personal Information when it can be associated with an individual using additional information.
8. Account confidentiality and sensitivity
Individual general-ledger accounts can be assigned a sensitivity level that PipeLedger applies across supported governed delivery surfaces in accordance with the applicable configuration and Documentation.
- Standard access can retain permitted transaction fields.
- Restricted access can remove identifying fields while retaining the financial line.
- Highly Restricted access can remove transaction grain and fold protected detail into ledger-level aggregates with limited accounting context.
The aggregation process is designed to preserve amounts required for supported reports and reconciliation checks while withholding protected transaction-level detail. Results remain dependent on source-data completeness, mappings, configuration, and documented limitations.
9. Consistent delivery policy
PipeLedger uses a shared delivery-policy architecture for supported product interfaces, MCP tools, REST APIs, CLI operations, web-terminal functions, and configured Business Intelligence sources. The architecture is designed to evaluate applicable scope, account-confidentiality, identity-privacy, memo, publication, and release controls before returning governed data.
Coverage can vary by feature and delivery mode. New or experimental surfaces must be reviewed before being represented as governed by the same policy contract.
10. Corporate Insider mode
Organizations managing material nonpublic or pre-release financial information can configure Corporate Insider mode. The feature is designed to separate governed financial data into insider and public delivery channels and reduce the risk that unauthorized users or agents receive pre-release numbers.
- Two channels. The insider channel is intended for information designated by the customer as not yet released. The public channel is intended for information designated by the customer as released for public-channel delivery.
- People and agents. The shared delivery-policy layer is designed to apply configured insider authorization rules to supported human, service-credential, and connected-agent delivery surfaces.
- Scoped credentials. Under the current documented configuration model, insider credentials must receive a defined scope. The Service does not provide an ordinary agent-level control that bypasses the configured insider policy.
- Refusal behavior. The standard refusal response is designed not to disclose the configured release date or other embargo metadata.
- Scheduled release. An approved reporting period may be assigned a release date. The Service is designed to initiate promotion to the public channel at the configured release time, subject to service availability, valid configuration, dependency availability, and authorized intervention.
- Evidence. Covered access, approval, and release events are recorded using append-oriented audit mechanisms subject to documented event coverage, retention, legal, security, and system limitations.
Corporate Insider mode is a configurable technical access and release-control feature. It is not a securities-law compliance program, legal information barrier, disclosure control, insider-trading control, or guarantee against unauthorized or premature disclosure. The customer remains responsible for identifying material nonpublic information, authorizing insiders, administering trading restrictions, approving disclosures, supervising connected agents, and complying with applicable securities laws.
11. Connected AI applications and agents
PipeLedger transmits governed data to an AI host or connected application in response to requests made through a customer-authorized integration, user, or credential, subject to applicable system, security, support, and legal processes.
Once a governed response reaches a third-party host, the host's terms, privacy practices, security, retention, training settings, and workspace-administrator controls apply. PipeLedger does not control host-side processing. Customers should select enterprise privacy settings appropriate to the information they authorize and should supervise agents that can initiate queries or downstream actions.
OAuth-connected applications may receive protocol protections such as managed authorization flows and audience binding. Customers may also create service credentials where supported. A credential may exercise the access permitted by its assigned scope and the governance policies evaluated when a request is processed.
For contractual, audit, and billing purposes, activity performed using a customer-minted credential is attributed to the customer, except as provided in the applicable agreement. Customers are responsible for narrow scopes, IP restrictions where available, rotation, secure storage, monitoring, and prompt revocation.
Agent-generated conclusions are not PipeLedger accounting, audit, investment, legal, or tax advice. Customers must independently validate outputs before using them for a filing, disclosure, payment, journal entry, tax position, credit decision, employment decision, or other material action.
12. Usage, billing, and query evidence
When an authorized application calls a PipeLedger feature or tool, PipeLedger records private usage information for security, reliability, quota enforcement, audit, and billing. Depending on the request, this may include the accountable organization-scoped credential, feature or tool, status, timing, row count, warehouse execution measurements, FCU or FIQ units, opaque request identifiers, and organization-scoped hashed host-session references.
The standard usage and billing event schema is not designed to store host conversations, user prompts, assistant messages, generated SQL, or returned financial rows. Query reconciliation can use structural metadata and cryptographic fingerprints rather than readable predicates, selected columns, scope values, or result rows.
Successful governed queries are designed to generate customer audit evidence using append-oriented mechanisms and the documented event schema. The standard self-service evidence interface restricts a connected credential to evidence associated with that credential, while authorized organization administrators and PipeLedger security, support, or legal personnel may have broader access appropriate to their roles.
13. Encryption and key management
Managed cloud services protect supported stored data using encryption at rest, and supported browser and API traffic is protected using HTTPS/TLS.
ERP connector credentials are designed to be stored using envelope encryption under managed key-encryption keys, with key versioning and rotation support.
Eligible Enterprise organizations may configure customer-managed Cloud KMS keys for supported data-warehouse datasets and cloud-storage resources. For supported resources, PipeLedger is designed to verify applicable key configuration before covered operations. While the required customer-managed key is disabled or unavailable, ordinary platform access to supported resources encrypted with that key is designed to fail.
Key revocation is not deletion and may not affect metadata, logs, exports, caches, backups, third-party copies, or resources not protected by that key. Customers are responsible for the availability, permissions, rotation, and lifecycle of their customer-managed keys.
14. Audit integrity and limitations
PipeLedger records categories of material administrative and governance events identified in the Documentation using append-oriented audit mechanisms. These records can support customer review, incident investigation, billing reconciliation, publication evidence, and governance oversight.
"Append-oriented" does not mean that every possible event is recorded forever or that records are immune from every legal, retention, corruption, administrative, or system process. Event coverage, authorized access, retention, backup, export, and correction procedures follow documented controls and applicable agreements.
Audit evidence is not a substitute for the customer's legally required books and records, internal controls, compliance program, audit procedures, or independent evidence.
15. Customer responsibilities and human oversight
PipeLedger provides financial-data infrastructure and governance tooling. Customers remain responsible for:
- the authority and lawful basis to connect and process Customer Data;
- source-system accuracy and completeness;
- accounting policies, mappings, classifications, and configurations;
- membership, roles, service credentials, identity grants, memo settings, sensitivity levels, and dimension scope;
- review of data-quality, publication, reconciliation, and certification-status evidence;
- supervision of connected applications and AI agents;
- filings, disclosures, journal entries, payments, tax positions, and business decisions; and
- engaging qualified accountants, auditors, tax professionals, legal advisers, and other professionals where appropriate.
16. Changes and additional information
We update this overview as the product and its controls evolve. The version and update date appear at the top of the page. Historical versions are listed at /legal/versions.
For binding terms, see the Subscription Agreement & Terms of Service. For information about Personal Information, see the Privacy Notice. Enterprise customers may request executed Security Addenda, negotiated Data Processing Addenda, or SLAs through support@pipeledger.ai.