The short answer
TallyPrime can expose data to external applications through documented integration routes including XML over HTTP and ODBC, and TallyPrime 7.0 introduced native JSON/JSONEx capabilities. These are TallyPrime capabilities. A Power BI workflow still needs a deliberate extraction method, table grain, relationships and reconciliation.
Four routes you will encounter in 2026
| Route | What it means | Power BI implication |
|---|---|---|
| XML over HTTP | A third-party application posts Tally XML requests to the running TallyPrime HTTP service and receives XML responses. | Useful for a controlled extraction layer that then prepares reporting tables. |
| ODBC | TallyPrime can act as an ODBC server for external applications where the required data is exposed. | Can support direct query/extraction patterns, but table semantics and reporting grain still need modelling. |
| Native JSON / JSONEx | TallyPrime 7.0 introduced native JSON capabilities for integration. | JSON availability does not by itself create a Power BI financial model or prove a particular third-party product supports that route. |
| Prepared reporting files/schema | An extraction process writes controlled facts and dimensions for BI. | Power BI reads a stable reporting layer rather than modelling raw transport responses directly. |
XML over HTTP: what the official prerequisites mean
Tally's integration documentation describes HTTP/XML exchange with TallyPrime running and the relevant company loaded. The external application sends a request to the configured Tally service and receives the response. That makes the running Tally session part of the integration boundary.
TallyHelp: XML integration → TallyHelp: integration prerequisites →
ODBC: useful, but not the same as a finished finance model
TallyPrime can expose data as an ODBC server. That can be useful for external reporting applications, but the reporting designer still has to understand what each table or collection represents, how identities behave and which values can be aggregated safely.
JSON in TallyPrime 7.0 does not mean every integration should switch to JSON
TallyPrime 7.0 introduced native JSON and JSONEx integration capability. That is a product-version capability, not evidence that every existing XML or ODBC integration should be replaced. The actual returned structure, required objects and reporting semantics still need to be validated for the use case.
TallyHelp: native JSON integration →
The Power BI problem begins after transport succeeds
Voucher headers, ledger entries, inventory movements and financial statements do not have the same grain. A useful model should preserve those differences so a voucher amount is not repeated for each ledger or inventory row and a balance-sheet position is not aggregated like a P&L movement.
This is the part many connector descriptions skip: getting a response from Tally is not the same as producing a reconciled accounting model.
Datplan's current development direction
Datplan's current Tally engineering path uses a catalogue-driven local HTTP/XML workflow. The planned BI layer is intended to keep voucher, ledger and inventory facts separate and to preserve proven provider financial-report outputs as separate reporting facts where their row identity, period behaviour and reconciliation are validated.
Datplan is not announcing native JSON support, an ODBC driver, DirectQuery, a finished PBIX/PBIT template or a public release date on this page.
See the TallyPrime development page → See the existing Datplan BI-export approach →
How to choose a route
- Choose by the TallyPrime version actually installed.
- Check whether the company must be loaded and the service enabled.
- List the exact reports, masters and transactions needed.
- Define row grain before building Power BI relationships.
- Reconcile high-level finance measures to Tally's own reports.
- Do not assume a transport method guarantees every custom field or report.
Start with the installed TallyPrime version and configuration
Do not choose a transport from a generic tutorial before checking the installed version. TallyPrime 7.0's native JSON capability changes the available options, while existing XML/HTTP and ODBC routes remain relevant. Confirm the company, service configuration and exact data/report requirement before designing the downstream model.
Financial reports and transaction detail should not be forced into one shape
A trial balance or balance sheet carries reporting semantics that differ from a voucher or inventory movement. A robust BI design can preserve high-level Tally report output for reconciliation while using detailed voucher, ledger and inventory facts for drill-down. That gives Power BI both an accounting control total and analytical detail while preserving the distinct meaning of those rows.
Questions to ask any Tally-to-Power-BI product
- Which TallyPrime versions are explicitly supported?
- Does TallyPrime have to be running with the company loaded?
- Is the transport XML/HTTP, ODBC, JSON, a proprietary driver or another service?
- Which masters, vouchers, ledger entries, inventory movements and reports are available?
- How are stable identities and dates handled?
- How are P&L and balance-sheet totals reconciled to Tally?
- Where is the copied source data stored?
- What happens when a pull is incomplete or a report shape changes?