What analytics ingestion covers today
Analytics ingestion today connects a single source type, an enterprise data warehouse, to a single record type, usage. The pipeline reads usage rows from tables you expose in your warehouse and loads them as consumption against usage-based performance obligations in Revenue Recognition. Nothing else is ingested through this path: other source systems and other record types are not supported yet. This matters because usage-based obligations recognize revenue from the consumption you report, not on a fixed schedule. See Usage and Tiered Pricing for how DualEntry prices that consumption. Analytics ingestion is one of two supported ways to feed usage: a continuous warehouse-sourced feed, versus the manual file upload described below.How ingestion compares to the manual usage import
Analytics ingestion and the manual usage import write to the same place, usage on your contracts’ performance obligations, but suit different workflows. Choose based on where your usage data already lives and how often it changes.- Analytics ingestion suits teams whose usage already lands in a warehouse as part of a product-analytics or metering pipeline. Once the source is connected, DualEntry reads the warehouse rows without a person assembling a file each period.
- Import Multi-Contract Usage suits teams that produce a periodic CSV or XLSX and want to validate and post it by hand through the bulk import wizard, with a row-level error report.
What gets ingested
A usage record is the unit analytics ingestion loads, and its shape matches the usage model used everywhere else in DualEntry. Each row identifies the contract and item it applies to, the date consumption occurred, and the quantity consumed. DualEntry resolves the item to a usage-based performance obligation on the named contract, then prices the quantity with that obligation’s flat or tiered schedule. The fields are the same ones documented for the manual path: contract, item or SKU, usage date, and quantity, with an optional existing usage identifier for updates. For the full field definitions, types, and matching rules, see the field table in Import Multi-Contract Usage. A row is rejected when the contract is missing, when the item matches zero or multiple usage obligations on that contract, or when the matched obligation is not usage-based.Connecting a data warehouse source
Connecting a warehouse as an ingestion source follows DualEntry’s warehouse connectivity pattern: you provide read credentials for your warehouse, DualEntry validates connectivity, and the credentials are stored in AWS Secrets Manager rather than in DualEntry’s own database. This is the same secure credential handling the warehouse export connectors use, applied to reading instead of writing. The exact credentials depend on the warehouse: Snowflake and PostgreSQL-compatible sources use an account or host with a username and password, while BigQuery authenticates with a Google Cloud project and a service-account key instead of a username and password. See Snowflake or PostgreSQL for how that credential lifecycle works in detail. The specifics of each ingestion source, which tables or views DualEntry reads, how source columns map to the usage fields, and how often the feed runs, are configured for your deployment rather than self-served from a settings screen. Work with your DualEntry implementation team to point ingestion at the right warehouse objects and confirm the column mapping before the first load. Keep your contract and item identifiers stable in the warehouse so each row resolves to the same obligation on every run.Current limitations
Analytics ingestion is intentionally limited today, and knowing the boundaries avoids surprises. The constraints below reflect what the pipeline does now, not a permanent design.- Source type: an enterprise data warehouse is the only supported source. There is no ingestion from other external systems through this path today.
- Record type: usage is the only record type ingested. Support for additional record types is planned, which is why the pipeline is built as a generic framework rather than a usage-specific one.
- Pricing and recognition are unchanged: ingestion only delivers consumption data. Each obligation’s pricing model and recognition timing are configured on the contract, not in the ingestion feed.
Because ingestion resolves every row to a single usage-based obligation, a usage edit can leave sibling rows out of date under tiered pricing. Before you close the period, run the reconcile dry-run on affected contracts as described in Usage and Tiered Pricing.
Next steps
- Configure pricing on each obligation first in Usage and Tiered Pricing.
- Use Import Multi-Contract Usage when you prefer a validated file upload over a warehouse feed.
- Review how DualEntry handles warehouse credentials in Snowflake and PostgreSQL.
- Return to the Data and Analytics overview or the full Integrations catalog.