AI-assisted development
Building a BI platform when the business starts in Excel
The first version began with four files and a practical question: which customers still owed money? The obvious answer was to load the files and draw charts. The useful answer required understanding what each file represented in the operating process.
DMS described supplier-side sales. MISA described accounting records and payment status. A mapping workbook decided whether a customer belonged to owned sales or delivery-only operations. The bank statement provided evidence of payment, but not always enough structure to identify the customer automatically.
The lesson
Excel was not the problem. Unstated relationships between files were the problem. Once those relationships became explicit, the system could evolve from a dashboard into ETL, reconciliation, inventory and financial reporting.
AI accelerated implementation, but it could not decide which source represented business truth. That remained an operating decision.
Data quality
The total row that became a customer debt
An early sales export ended with a summary row. It had a large amount but no valid customer code. The first parser treated every row as a transaction, so the dashboard created an enormous “unclassified customer” receivable.
The visual was wrong, but the root cause was not visual. The input contract was incomplete.
What changed
The pipeline added structural validation: summary labels, missing identifiers and known footer patterns are rejected before business calculations. The same principle later applied to bank totals, empty sell-in rows and inventory lines without monetary ownership.
A dashboard can make a bad row look authoritative. Validation must happen before aggregation.
Architecture
Why business logic matters more than the chart
Two customers can have the same name but never the same code. A customer may appear in sales data but represent delivery-only activity, not owned revenue. A sample order has no selling value but still reduces inventory. A pack code may be sold as individual units.
None of these rules are chart settings. They determine what the number means.
Design implication
The platform keeps calculations behind Python service endpoints and exports the same normalized logic to Power BI. The charts are replaceable. The business definitions are the durable asset.
What I would do next
Move source adapters behind explicit interfaces, add automated reconciliation fixtures and replace file polling with vendor APIs when access becomes available. The current architecture deliberately leaves room for that transition.