Skip to main content
Connecting Power BI to DualEntry does not push data into Power BI. DualEntry exports your accounting data into a relational database that you own, and Power BI reads from that database. The Power BI tile in DualEntry is where you register that database and run the export. That ordering determines what you have to supply. You provide the destination: a PostgreSQL, Snowflake, or SQL Server database that DualEntry can reach and write to. DualEntry does not host a database on your behalf, and there is no Power BI API credential to paste anywhere.

​
Prerequisites

Confirm the following before connecting Power BI:
  • A destination database you control, running PostgreSQL, Snowflake, or SQL Server. This is where DualEntry writes; Power BI never talks to DualEntry directly.
  • Network reachability from DualEntry to that database. If it sits behind a firewall or VPC, your platform team may need to allow DualEntry’s egress IPs.
  • TLS configured on the database. DualEntry requires TLS by default on PostgreSQL and SQL Server destinations, and stricter certificate verification is available. See PostgreSQL for the SSL modes and how to set one.
  • Credentials for a database user with permission to create and write tables in the destination database.
  • Permission in DualEntry to create export destinations.
  • Power BI Desktop or the Power BI service, with the matching connector for your database engine.
One active Power BI export integration is allowed per organization. The same single-active rule applies to the other export destinations (PostgreSQL, Snowflake, and Qlik).

​
Choose your destination database

The Power BI tile asks which database engine you are exporting into, because Power BI itself is the consumer rather than the destination. Your answer determines which credential fields you fill in. Credential fields collected per engine, all required unless noted: Pick the engine your BI stack already runs on rather than standing up a new one. Power BI connects to all three natively, so the choice is about what your team already operates and secures, not about what DualEntry supports better. If you already have a PostgreSQL or Snowflake export destination configured, that database is already receiving DualEntry data and you can point Power BI at it directly. Setting up Power BI as a separate destination is only worth doing when you want an export that is independent of the existing one.

​
How to connect

DualEntry validates the credentials in the background, then stores them in AWS Secrets Manager. Passwords never persist in DualEntry’s own database.
  1. In DualEntry, navigate to Configuration → Company → Integrations and choose Power BI.
  2. Under Select Your Database, choose PostgreSQL, Snowflake, or SQL Server.
  3. Fill in the credential fields for that engine, then choose Sign in.
  4. Wait while the destination shows Validating. DualEntry opens a connection to your database using the credentials, then closes it. A clean open and close counts as validation.
  5. On success the destination shows Connected. On failure it shows the error returned by the database, and you correct the credentials and try again.
A failed destination does not retry on its own. Fix the underlying cause and sign in again rather than waiting.

​
Run an export

Power BI exports run on demand. After the connection validates, a Sync Settings section appears with a Last Sync timestamp and a Sync Now button. Choose Sync Now to start an export run. Each run is a full snapshot rather than an incremental update. DualEntry writes every table in the export schema, uploads the result, catalogs it, and loads it into your destination database. Progress is visible on the tile while the job runs, and the Last Sync timestamp updates when it completes.
Scheduled exports currently run for Snowflake destinations only. A Power BI destination exports only when someone chooses Sync Now, so assign that step to whoever owns your reporting refresh rather than assuming data appears overnight.
One export job runs per organization at a time. If a job is already in progress, starting another is rejected until the first finishes, and you cannot disconnect the integration while a job is running.

​
What lands in your database

The export writes DualEntry’s ledger and subledger data as a set of tables, organized into seven groups. Knowing the shape up front saves rebuilding your Power BI model after the first run. The exported table groups:
  • Core: companies, accounts, vendors, customers, transactions, entries, and payment methods.
  • Classifications: classifications and classification lines, plus the classification links on entries and on order, deposit, payment, and obligation lines.
  • Money out: bills, direct expenses, purchase orders, vendor credits, vendor payments, vendor prepayments, and vendor refunds, each with their line tables.
  • Money in: invoices, cash sales, customer prepayments, credits, refunds, payments, deposits, and revenue recognition, each with their line tables.
  • Journal: journal entries, intercompany journal entries, bank transfers, and allocation journals, each with their line tables.
  • Assets: fixed assets, asset classes, depreciation schedules, depreciation, disposals, amortization, revaluation, and currency revaluation.
  • Records: sales orders, contracts, performance obligations, obligation usage, change orders, terminations, allocation schedules, recurring records, and reconciliations.
Every row carries two metadata columns, cdc_schema_version and cdc_exported_at, which tell you which export schema version produced the row and when the snapshot was taken. Use cdc_exported_at in Power BI to show report consumers how fresh the data is, since the export is a snapshot rather than a live feed.

​
Connect Power BI to the database

With data in your destination database, the Power BI side is an ordinary database connection and involves nothing DualEntry-specific.
  1. In Power BI Desktop, choose Get data and pick the connector for your engine: PostgreSQL database, Snowflake, or SQL Server.
  2. Enter the same server and database values you registered in DualEntry, and authenticate with a database user that has read access.
  3. Choose Import or DirectQuery. Import suits the snapshot model, since each export replaces the data wholesale rather than streaming changes.
  4. Select the tables your report needs and build your model.
Point Power BI at a read-only user rather than reusing the credentials you gave DualEntry. The DualEntry user needs write access to load the export; your report consumers do not.

​
Disconnect

Disconnecting archives the stored credentials, marks the integration as Disconnected, and schedules deletion of the AWS Secrets Manager entry. The data already written into your destination database stays there; DualEntry does not drop the tables it created, so existing Power BI reports keep working against the last exported snapshot. You cannot disconnect while an export job is running. Wait for the job to finish, then disconnect. Disconnect and reconnect is also how you rotate credentials. There is no in-place edit: once a connection validates, the username and password fields are masked and locked, so changing either means disconnecting and signing in again with the new values. Plan a rotation for a window when no export is running and no report refresh depends on a sync completing.

​
Troubleshoot connection and export errors

Validation and export both run in the background, so errors surface on the integration tile rather than as an immediate response.
  • PostgreSQL - the same export pipeline with PostgreSQL as the named destination, including the full credential schema and SSL modes
  • Snowflake - the warehouse destination, and the only one that supports scheduled exports today
  • Integrations - the full connector catalog
  • Power BI data source documentation - Microsoft’s reference for the database connectors named above
Last modified on September 15, 2026