A company view was missing from detailed operating data
The client had detailed records for individual products, but revenue, acquisition spending, payroll and operating costs were spread across platforms, bank exports and internal files. Multiple legal entities and currencies added another layer of complexity.
In a mobile-app business, subscription revenue might sit in RevenueCat, acquisition performance in Adjust, contractor payments in Deel, and other expenses in bank exports and internal spreadsheets. Each source describes a different part of the business.
My job was to bring those different views together so the company could see its overall result and still understand what was happening inside each app and cost category.
Turning transaction detail into meaningful business categories
A substantial part of my work was going through a large volume of varied transactions and deciding how to group them. The categories needed to be few enough to make the business understandable, but specific enough to explain where the money was going. That balance was an important part of the model.
I connected those categories to business functions, cost centres and the company P&L, keeping the original records available underneath. These were the main decisions behind the structure:
- Separate source schedules
- Product revenue and acquisition retain their own logic; transaction-based costs join them in the company P&L.
- A manageable classification
- Financial categories, functions and cost centres make the totals interpretable without losing the underlying records.
- Rules with exception review
- Recurring patterns follow the same treatment, while unmatched transactions remain visible for a decision.
- One basis for actuals and forecasts
- Consistent categories connect historical reporting with future planning.
New records follow the same classification logic
Supported bank exports, contractor reports and internal files are converted into common fields: description, date, currency and amount. Each new source layout needs its own field mapping.
Once the categories were defined, I built reusable rules around them. A familiar transaction follows the same treatment each time. If a record does not match, it stays visible for review; the next decision can become a rule for future imports.
Workbook capture
Reporting periods and exchange rates convert the imported data into reporting values. Internal transfers are excluded from the P&L. The demonstration follows one bank-file import through this process.
From the company result to the costs behind it
The consolidated P&L brings product revenue and acquisition schedules together with payroll and operating expenses. Management can review revenue, gross profit and EBITDA, then look into the schedules that explain those totals.
Costs remain available by function and cost centre, while product schedules preserve the detail for individual apps. Actuals and forecasts use the same financial categories, providing a consistent basis for comparing performance with the plan.
Workbook capture
What the model enables
I built the model to remain useful when the next set of files arrived. The company can bring in new records, review anything that needs a decision and follow the updated numbers through to its P&L and plans.
- Review the overall result
- A consolidated P&L across apps and legal entities.
- Understand the underlying costs
- Trace reported expenses into their categories and supporting detail.
- Update reporting and plans
- Bring new records and forecasts into a consistent financial structure.
The main work in this project was deciding how the company’s financial information should fit together. The import workflow made that structure repeatable. A manageable set of categories made it understandable. Together, they connected the overall company result to the records behind it—the level of detail needed to investigate costs and keep the model useful as new data arrived.