What data does your accounting package offer?
Accounting packages are built first and foremost to do bookkeeping, not reporting. Even so, there is usually enough to build a solid dashboard on. Think of sales invoices, purchase invoices, contacts (customers and suppliers), ledger entries and sometimes payment status. Depending on your package, your plan and the permissions your account has, that offering can differ quite a bit. One package gives you access to individual invoice lines, another only to invoice totals.
Before connecting anything, it is worth checking exactly what is available through your package's API, and whether your plan and user rights allow it. That prevents discovering halfway through a project that a field you needed is not exposed.
Working with Moneybird or Odoo? We often already have experience with the specific fields and limitations of those packages. Take a look at our Power BI to Moneybird integration or the Power BI to Odoo integration for a concrete picture. Using a different package? The principle is the same, only the details differ.
Which KPIs make sense from your accounting data?
Not every number you can pull is a good steering metric. From accounting data, these topics tend to be useful:
- Revenue development by month, customer or product, provided the invoices carry enough detail.
- Outstanding invoices, so you spot late-paying customers in time.
- Margin, when sales and cost lines can be linked to each other.
- Customer concentration: how much revenue depends on a small number of customers.
- Cash flow indication based on outstanding sales and purchase invoices.
It is tempting to build dozens of charts right away. It works better to start with two or three questions that genuinely help you steer, and work those out with the right definitions. The rest can follow later.
Definitions to set upfront
Most discussions about a dashboard are not about the technology, but about what a number actually means. So agree on a few things beforehand:
- Which date leads. The invoice date, the shipping date and the payment date can each give a different picture of "revenue this month". Pick one and stick with it.
- How credit notes count. Do you deduct them from revenue in the month they were issued, or correct the original month? Both are defensible, but they need to be consistent.
- Revenue including or excluding VAT. For steering purposes you almost always want to report excluding VAT, but the package sometimes returns amounts including it. Check this per field, not per report.
- What counts as a "customer". If the same customer appears under two different names in the system, you will count them twice. That calls for cleaning before you connect.
These agreements do not need to be perfect, but they do need to be written down somewhere, so everyone speaks the same language.
API access and permissions
To let Power BI refresh automatically, you need access to your accounting package's API. That usually means setting up a connection or app authorisation, often by someone with administrator rights. Arrange this early: if the person with the right rights is on holiday, the project stalls.
Also pay attention to what the API does and does not return. Some fields are only visible on a higher plan, and not every package returns the same amount of historical data in one go. Ask your provider or test it upfront, rather than assuming everything is available.
Also think about who should have access to the underlying data later. A dashboard with revenue per customer is sensitive information. Manage permissions in Power BI just as carefully as in the accounting package itself.
Historical data and refresh frequency
An accounting package often mainly shows the current state. If you want to show trends, such as monthly revenue over the last two years, that history needs to be stored somewhere from the moment you start connecting. Do not wait too long: the sooner you start building history, the sooner you have a usable trend line.
For refresh frequency: choose a schedule that fits how you use the dashboard, not necessarily the fastest possible one. If you want to see yesterday's numbers in the morning, a daily refresh is usually more than enough. For most accounting-based steering information, real time is rarely needed and often unnecessarily complex to build and maintain.
These kinds of choices are best made as part of a broader data engineering effort, where fetching, storing and cleaning sit separately from the dashboard itself. That way Power BI does not have to redo the heavy lifting every time, and adding another source later becomes easier.
Common pitfalls and a proper handover
A few things that often go wrong when connecting an accounting package:
- Connecting straight away without definitions. That gives you a technically working dashboard nobody trusts, because the numbers do not match what the accountant reports.
- Trying to expose everything at once. Start with the question that helps you most, such as outstanding invoices or revenue per customer, and expand from there.
- Ignoring permissions. If the connection is set up under one person's name and they leave, the refresh stops working. Record who owns the connection.
- No documentation at handover. A dashboard without an explanation of the definitions and data sources used is hard to hand over to a new colleague or another agency.
Working with an external agency? Make sure you get a clear handover: which definitions were used, how the connection is set up, who has access and where the documentation lives. That is exactly how we approach it in our approach: start small, show something working quickly, and deliver the whole thing in a way that can be handed over, with dashboarding that fits how you steer. For a concrete starting point, check our integrations page, or look at the integration with Moneybird or Odoo.
