Fruit processing group · Bulgaria · major European processor, seasonal, export-led
Board-Level Power BI Reports on a Fruit Processor's Bespoke ERP
Stock decides every sales and production move in a seasonal fruit business, yet the CEO and the board had no clear view of it. Their bespoke ERP captured everything, reported next to nothing and had no documentation. Today leadership follows finance, production, sales and stock in Power BI, fed by live ERP data, with each audience limited to what it should see.

- Industry
- Manufacturing
- Function
- Finance & Accounting
- Region
- Bulgaria
Results
- 4
- reporting areas, one shared model
- Finance, production, sales and available stock, all on live ERP data.
- 0
- pages of ERP documentation available
- We analysed and mapped the database from zero. A measure of scope, not of savings.
- 3
- audiences, each with role-based access
- Board members, executives and the CEO, each limited to what it should see.
01
The challenge
The client is one of Europe's leading fruit processors. This project covered its Bulgarian operations, a seasonal processing business built around exports. In Bulgaria the company runs a bespoke ERP developed locally. The operational data was all there, but the system offered too few reports and no visuals at all, so leadership had little to manage by.
No vendor reporting existed to fall back on. Nor was there any documentation of the ERP database that reports could be built from.
Where it hurt
- Stock decisions in the dark. In a seasonal business, how much raw and processed fruit is on hand shapes every sales and production call.
- Sales and production out of sight. Leadership could not see performance well enough to steer the season.
- Finance stitched together. Financial numbers were put together manually instead of coming from the system of record.
- An undocumented database. Building reports was hard when nobody had ever described the database behind them.
- A board with no market picture. The directors had no clear sense of where the company stood in its market.
02
What we did
We put a Power BI reporting layer on top of live ERP data. The first job was to understand the database on our own.
Six steps to board-ready reporting
- Reverse-engineering the database. There was no documentation, so we analysed the database itself to locate the stock, sales, production and finance data and work out how the pieces connect.
- Extraction and transformation. We pulled and reshaped the data from the ERP database using SQL and Power Query.
- A model built for decisions. Everything was arranged into a single reporting model that leadership can read, instead of a mirror of the ERP's tables.
- Live connection to the ERP. Reports draw on the system of record directly, never on exported files.
- Four areas covered. Finance, production, sales and available stock.
- Separate roles. Access controls make sure each audience, whether the CEO, the executives or the board, sees only what it is meant to.
Stack
| Layer | Tools |
|---|---|
| Source system | Bespoke ERP built locally, database analysed with no documentation |
| Data preparation | SQL and Power Query on the ERP database |
| Reporting model | Data model in Microsoft Power BI |
| Reports | Stock, sales, production and finance reports in Power BI |
| Access | Row-level security and role-based access in Power BI |
03
The outcome
One model now serves the CEO, the executives and the board. It runs on live ERP data, and each person sees the view their role permits.
| Before | After | |
|---|---|---|
| Stock, sales, production and finance | A handful of reports, no visuals | Four reporting areas in a single Power BI model |
| Finance numbers | Put together manually | Taken from the system of record |
| ERP database | No documentation | Analysed and mapped for reporting |
| Market position as the board sees it | Unclear | Clear, drawn from the same model |
- Essential reporting behind the CEO's decisions, used internally throughout the organisation.
- Executives and the board now see clearly where the company stands in its market.
- Finance, production, sales and stock in a single model, running on live ERP data.
- Reporting built on an undocumented ERP that had no native reports to start from.
This engagement did not record time savings or usage numbers. The figures above describe its scope.
Where bespoke ERP reporting goes wrong
Reports on an undocumented custom ERP break more easily than reports on a standard one. Column names may mean something other than what they say. Cancelled records may never be deleted. The schema can shift with the ERP developer's next update. A report that looks fine but counts cancelled stock, or counts transfers twice, loses the board's trust quickly. The real work is checking the model against numbers the business already trusts, writing down what we learned about the database, and keeping the reporting model isolated, so an ERP update breaks a single mapping rather than every report.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.

Accounting practice, Bulgaria · monthly close for a web shop handling 1,000-1,500 orders
Month-End Close Automation for a 1,500-Order Online Store
- for a whole month, reconciled and posted
- < 2 min
- for a whole month, reconciled and posted
- of sale records matched with no manual work
- 98%
- of sale records matched with no manual work

Accounting practice · Bulgaria · client: international data centre and hosting provider
Five Payment Channels Reconciled and Booked to AJUR Every Month
- invoices posted in one monthly run
- 600
- invoices posted in one monthly run
- of bank statement lines processed with no manual work
- 95%
- of bank statement lines processed with no manual work

Bulgarian accounting firm · 10-15 people · bookkeeping for 100+ client companies
Hands-Free Bank Statement Retrieval
- client companies handled twice a month
- 70+
- client companies handled twice a month
- bank portals driven by RPA
- 3
- bank portals driven by RPA