Connect Twinfield to Power BI via OData

Connect Twinfield to Power BI: what you will set up

The DigiData Twinfield connector synchronizes selected Twinfield offices and makes their data available to Power BI through a stable OData feed. The feed contains structured tables for transactions, debtors, creditors, general ledger accounts, projects, offices, and VAT codes that you can use in a financial data model.

This guide follows one route from start to finish: authorize Twinfield, select offices, open the OData feed in Power BI Desktop, create relationships, publish the report, and configure scheduled refresh in Power BI Service. If you first need to compare OData, CSV, a direct API, and AI access, use the Twinfield integration comparison.

Prerequisites and access checks

You need access to the Twinfield organization and the offices you want to report, a DigiData account, and Power BI Desktop. Twinfield API requests use an office or company context, so confirm which offices the authorizing user can open and record which office codes belong in the report.

Decide which totals and period you will use to validate the first version. A connection can work technically while a report still excludes an office, period, or reference table needed for the intended figures.

Step by step: load Twinfield data into Power BI

Step 1: connect Twinfield to DigiData

Sign in to the DigiData dashboard and add a Twinfield integration. DigiData redirects you to Twinfield to sign in and authorize the connection through OAuth2. Select the offices you want DigiData to synchronize. DigiData does not store your Twinfield password.

Step 2: wait for the first synchronization

DigiData begins retrieving the selected data and shows the synchronization status in the dashboard. The time required depends on the selected offices and the amount of source data. Continue when the tables required for your report have completed their first synchronization.

Step 3: open the OData connector in Power BI Desktop

Open Power BI Desktop, select Get Data, and choose OData Feed. Use the connector included with Power Query rather than building a Twinfield API client inside the report.

Step 4: enter the DigiData service-root URL

Copy the OData service-root URL from the DigiData dashboard and enter it in Power BI. Authenticate using the credentials and method supplied for the feed. The Navigator then shows the available tables, such as transaction headers, transaction lines, debtors, creditors, general ledger accounts, projects, and offices.

Select only the tables the first report needs and choose Transform Data. In Power Query, check data types, remove unused columns, and apply necessary period filters before loading the model.

Step 5: build the model and publish the report

Use transaction lines as the fact table for many financial reports. Connect them to dimensions such as general ledger accounts, projects, debtors, creditors, offices, and a dedicated date table. Prefer stable IDs and office codes over names when creating relationships.

After validating the model, publish it to Power BI Service. Open the semantic-model settings, enter the OData source credentials for the Service environment, and configure scheduled refresh after the DigiData synchronization normally completes.

Fix missing offices, rows, or refreshes

If an office is missing, check both the Twinfield user's access and the office selection in DigiData. A successful sign-in does not grant access to every office. If specific rows are missing, compare the office code, accounting period, and Power Query filters with the source.

If the report refreshes in Power BI Desktop but fails in Power BI Service, check the saved source credentials and authentication method in the Service. Test the unchanged service-root URL before adding query options. Put filters in Power Query so the cloud connection does not depend on a manually assembled table URL.

A successful Power BI refresh can only retrieve the data currently available in the OData feed. Check that the DigiData synchronization completed before investigating the report model itself.

Which Twinfield tables can you use?

Supported reporting tables include transaction headers and lines, debtors, creditors, general ledger accounts, cost centers, projects, offices, and VAT codes. The exact records available depend on the selected offices, Twinfield permissions, and source data. The Twinfield connector page provides the current connector details.

Start with a narrow set that answers one reporting question. A finance overview may need transaction lines, general ledger accounts, offices, and dates. Receivables analysis also needs debtor data. Project reporting may add projects and cost centers.

Build a verifiable Twinfield data model

Create a model whose totals can be traced back to Twinfield. Keep transaction lines at their natural level of detail and relate them to reference tables through stable identifiers. When several offices use the same local account code, include the office context in the relationship where needed.

Add a separate date table for period filtering and time-based measures. Define revenue, costs, outstanding items, and cash flow explicitly in the model instead of relying on visual-level calculations that are difficult to review.

Validate the first version with simple comparisons by office and period. Confirm revenue, costs, debtors, and creditors before adding cash-flow calculations, project results, or consolidated views.

Security, refresh, and pricing

The Twinfield authorization uses OAuth2, so DigiData does not store Twinfield passwords. The authorizing user's access and the selected offices determine the source scope. Power BI access remains a separate responsibility in your workspace.

Coordinate the two refresh moments. DigiData first synchronizes Twinfield, and Power BI then reloads the OData tables. Refreshing Power BI more often than the source changes does not make the underlying records newer.

DigiData charges per integration, without a setup fee, and offers a 14-day trial. Confirm the required offices and tables during the trial so the first production report starts from a verified scope.

Common Twinfield Power BI mistakes

Do not use Power Query as a direct Twinfield API client unless your team intends to maintain authentication, pagination, limits, and error handling inside the reporting solution. A managed OData feed keeps that source-specific work outside the report.

Do not load transaction lines without the reference tables needed to interpret them. Amounts need general ledger accounts, projects, offices, and other dimensions before they become a useful management report.

Do not postpone business definitions. Agree on the meaning of revenue, costs, outstanding items, cash flow, and reporting periods before the dashboard is distributed. DigiData supplies synchronized source records; the Power BI model supplies the relationships and measures.

Summary

Connecting Twinfield to Power BI does not need to become a custom API project. DigiData synchronizes the selected offices, and Power BI loads the resulting tables through OData. From there, you build a verifiable model and refresh it from one stable source. Start a 14-day trial from the Twinfield connector page or contact DigiData to discuss the reporting scope.