Power BI Dashboards for Trading Companies

A trading company needs a handful of dashboards built on agreed KPI definitions and clean ERP data: sales and margin, inventory, receivables and shipments. Power BI, Tableau and Looker Studio can all deliver them, so the tool decision follows your data sources, your users and your governance — not the feature list.

Which dashboards does a trading company need?

Trading businesses share a small set of management questions that repeat weekly, and each one is a dashboard rather than a report: Tell us the KPI dictionary your team argues about and we will quote the dashboards and the data model behind them: request a quote.

• Sales and margin. What sold, to whom, at what margin — by product, customer, market and month. The margin view is the one that changes behaviour: a trading company can grow revenue and shrink profit in the same quarter, and only the margin cut shows it.


• Inventory. What is held, where, for how long, and what has stopped moving. For distributors this is the cash dashboard: inventory days and slow-moving stock tie up the working capital that the next order needs.


• Receivables. Who owes what, for how long, and which balances crossed their due date. Ageing buckets make the difference between a normal book and a problem one visible at a glance.


• Shipments. What left on time, what is late, and what is stuck at a document or customs step. For exporters this is also a service-quality dashboard, because the delay the customer experiences is a shipment event, not an invoice event.


• Open orders. What is committed, what is pending, and what is blocked — the operational picture that decides this week's production, purchase and container plans.

KPI definitions and data sources

The table is the working core of the project: each KPI needs one definition, one owner and one source, and the pitfall column is where most dashboard disputes are born:

Table A: KPI | definition | data source | frequent pitfall

Two disciplines keep this table alive. Definitions are written in plain business language, not formulas — the formula belongs in the data model, the sentence belongs in the dictionary, and the sentence is what the commercial team argues with. And every definition carries a date and an owner: definitions drift as the business changes, and a dashboard running on last year's definition is quietly wrong rather than honestly stale. The wider question of whether this layer belongs in a new system or in the existing ERP is treated on the custom vs packaged ERP page, and the BI and data analytics page covers the wider discipline.

Data sources and integration

A trading company's truth is spread across five systems, and the BI layer's job is to join them without inventing anything:

• ERP. Invoices, orders, stock, payments, master data. The primary source, and usually the only one with transactional integrity.


• Spreadsheets. Targets, budgets, manual adjustments, and the shadow numbers that live in one person's file. Take them seriously — a budget that exists only in a spreadsheet is still a real budget — but bring them in as data with an owner, not as emailed attachments.


• E-commerce and marketplaces. Orders and traffic for companies selling online; channel data that rarely matches the ERP one-to-one, so the mapping rules (what counts as a sale, when) become part of the dictionary.


• Logistics. Dispatches, tracking references, carrier status — the source for the on-time KPI and the shipment dashboard, and the one that most often needs manual keys or partner feeds.


• Bank. Collections and payments, matched against open items — the bridge between the receivables dashboard and the cash reality.

Data model basics

You do not need to become a data engineer to get this right, but three concepts decide whether the project survives its second year:

• Facts and dimensions. Facts are the events — invoice lines, dispatches, payments — with quantities and values. Dimensions are the context — product, customer, market, date, warehouse — with the attributes you filter and group by. Every KPI in the table above is an aggregation of facts sliced by dimensions, which is why one model serves five dashboards.


• Star schema, deliberately. Keeping facts central and dimensions around them, without clever many-to-many shortcuts, is what keeps measures additive: sales summed by region equals sales summed by month equals total sales. Models that skip this structure work in the demo and break in the third report.


• One version of the truth. The same product code, customer code and currency in every fact table, sourced from the same master data. Duplicated dimensions that drift apart are how two dashboards start showing two different totals for the same month — and the argument that follows costs more than the model ever saved.

Power BI, Tableau and Looker Studio compared

All three deliver the dashboards above; the differences are in fit. The comparison is deliberately qualitative — licensing terms and feature sets in this market change frequently, so check current vendor information before deciding, and treat any figure older than the current release cycle as a hint rather than a fact:

Table B: criterion | Power BI | Tableau | Looker Studio

The honest way to decide is with your own constraints in the first column, not the products' in the rows: where the data lives (a Microsoft-centred estate favours Power BI simply on connectivity and identity), who the daily users are, and who will govern the model in two years. A procurement exercise that scores these rows against your written requirements — the method on the vendor RFP checklist — reaches a defensible answer; a demo comparing three homepages does not.

Access control and governance

Trading dashboards show margin, customer names and payment behaviour, so access is a commercial question before it is a technical one:

• Row-level security. A regional manager sees their region, a salesperson sees their accounts, the board sees everything — enforced in the data model, not in separate copies of the dashboard. Separate copies are how "two numbers for the same month" returns.


• Roles over reports. Access follows job roles, granted once and reviewed periodically; a leaver's access ending with their employment is a governance routine, not a project.


• Sensitive fields. Margin and cost columns deserve explicit decisions — who sees them at all, and whether a dashboard exists without them for wider circulation.


• Data protection. Customer personal data in a dashboard falls under the same duties the company already carries: KVKK for Turkish operations and GDPR for European customer data, covering lawful basis, retention of extracts and access logs. The duties are the same as for the systems the data comes from; a dashboard is not an exemption because it only reads. The wider contract context, including hosting and vendor access, is treated on the IT outsourcing page.


• Refresh and change control. A dashboard whose definition changes should change visibly — a version note, a date, an owner — because the quiet redefinition of a KPI is how two departments stop trusting each other's numbers.

Implementation steps

The sequence that works, in order:

1. Metric definitions first. The KPI dictionary, signed off by the commercial, finance and logistics leads. One or two pages; the entire project's failure risk sits in whether this step was done properly.


2. One data source, one pilot dashboard. Usually ERP invoices and the sales-margin dashboard — the question management asks most and the data that is usually cleanest. The pilot proves the pipeline, the model and the definition simultaneously.


3. User test with real questions. Give the pilot to three real users for two weeks with their actual weekly questions, and watch what they cannot answer. The gap list from that fortnight is the backlog that matters; the feature requests it generates are usually smaller than the fear of them.


4. Fix, then extend. Data quality issues found in the pilot get fixed at the source, not in the dashboard — a calculated fix in a report hides a dirty ERP that will poison every later dashboard.


5. Roll out by dashboard, not by user count. Ship the five agreed dashboards in sequence, each with its owner and its definition date, rather than opening the tool to everyone at once — the second half of the adoption problem is what people look at, and five owned dashboards beat an empty canvas.


6. Operate it. Refresh monitoring, a named owner per dashboard, and a quarterly definitions review. A BI project that ends at go-live becomes a reporting hobby within a year; the operating routine is what makes it management infrastructure.

Frequently Asked Questions

Do we need a data warehouse?

Not to start. A direct connection to the ERP plus a handful of dimension tables covers the first five dashboards for most trading companies; a warehouse earns its keep when source systems multiply, history must be kept beyond ERP retention, or performance suffers. The honest trigger is repetition: when the same extraction workarounds keep being rebuilt, that is the warehouse conversation — and the build-versus-configure question it raises is treated on the custom vs packaged ERP page.

How often should data refresh?

Match the refresh to the decision cycle, per source: sales and open orders justify daily or near-daily; stock and receivables usually daily; marketplaces and bank feeds as often as they reliably update. More frequent than the data actually changes buys cost without information, and refresh failures should be visible to users rather than silent — a dashboard showing yesterday's data as today's is worse than one that says it is late.

Can we use Excel exports?

Yes, as a legitimate source — many first dashboards run on a scheduled export routine, and budgets often live only in spreadsheets. The discipline is to treat exports as data feeds with an owner, a schedule and a format that is checked; the failure mode is the emailed file that arrives irregularly and quietly stops, taking a KPI with it.

Who defines the KPIs?

The business owners of the numbers: commercial leads for sales and margin, operations for inventory and shipments, finance for receivables. The BI team translates the agreed sentences into measures; when the BI team defines the KPIs alone, the dashboards measure something nobody asked for — technically correct, organisationally unused.

Is Power BI free?

Licence terms in this market change frequently, so check current Microsoft information before budgeting rather than relying on figures that may predate the current release cycle. What does not change is the shape of the decision: per-user subscriptions with roles, a modelling layer that needs governance, and a cost that is usually modest next to the decisions the dashboards improve — but decide on current terms, in writing.

How do we secure customer data?

Row-level security in the model so people see what their role permits; explicit decisions on margin and cost fields; access granted by role and reviewed periodically; and the KVKK/GDPR duties applied to the dashboard layer — lawful basis, retention of extracts, access logs — exactly as for the source systems. The hosting and vendor-access questions are the same ones treated on the IT outsourcing page, and they belong in the contract before go-live.

Sources and standards

• The KPI set, data-source mapping, modelling concepts (facts, dimensions, star schema, one version of the truth), governance topics (row-level security, refresh visibility, change control) and rollout sequence follow general business-intelligence practice for trading and logistics companies; no usage statistics, adoption figures or measured results appear on this page.
• The three-tool comparison is deliberately qualitative and free of licence prices, limits and feature claims that change between release cycles; every licensing row instructs the reader to check current vendor information, and no partnership with Microsoft, Tableau or Google is claimed.
• Process statements follow this site's pages: BI and data analytics, custom vs packaged ERP (where the data layer belongs) and IT outsourcing from Türkiye (KVKK and GDPR duties, vendor access, contract questions).
• Data protection duties are named, not interpreted: KVKK for Turkish operations and GDPR for European customer data apply according to the company's situation; confirm the applicable regime with a qualified adviser.

Related pages

BI and data analytics · Custom vs packaged ERP · Software development · Vendor RFP checklist · AI automation · Request a quote