Case · Financial operating system

How I Rebuilt a P&L We Could Not Trust

The company made handcrafted confectionery gifts and sold them online, both directly and through marketplaces. When I joined, all management reporting lived in one relatively simple spreadsheet. It contained sales, revenue, expenses, and cost of goods, but mixed different accounting methods together.

Revenue might enter the report when cash arrived. Packaging and ingredients appeared in the month they were paid for. Inventory and balances owed between periods were not properly accounted for. As a result, the P&L could not explain why the amount of cash in the bank had changed the way it did.

This made the profit reported for any given month unreliable. A large packaging purchase, for example, would immediately make that month look worse even though the packaging would be used over several months. The spreadsheet showed cash movement, not the actual economics of sales during the period.

At the end of February 2022, I took over reporting together with responsibility for the commercial side of the business. I saw the main risk immediately: we could not base decisions on these numbers. First, I had to reconstruct the accounting logic behind them.

First iteration: the full cost of each product

I first wanted a complete view of the company and an explanation of its financial result. I began with a detailed cost calculation: I broke each product down into ingredients and packaging, then allocated the production team's labor across the chocolates it produced.

For handmade chocolates, this seemed logical. The product could not exist without a chocolatier's work, just as it could not exist without its ingredients, so the labor appeared to belong in the cost of every chocolate.

The spreadsheet did calculate costs at that level of detail. Whenever an ingredient price changed, I added another column for the new period, entered the updated values, and extended the formulas. The costs of all products were then recalculated automatically.

But the spreadsheet grew with every new period and became increasingly difficult to maintain. Later, the production technologist took over the recipes and ingredient prices and began giving me the completed cost of each product.

Labor created a separate problem. Production was seasonal, workload varied, and the team was paid per shift. The labor cost allocated to one chocolate therefore depended on how busy a shift happened to be: for the same pay, the team could make different quantities of product.

Second iteration: separating product costs from operating expenses

Eliyahu Goldratt's The Goal helped me resolve the labor question. It suggested a different test: not whether a cost was connected to production, but whether that cost would increase if we made one more box.

Ingredients and packaging were consumed for every additional box. The team was paid for a shift, not for the number of chocolates produced. I therefore kept materials in the product cost and moved labor into the operating expenses of the business.

The book's idea of throughput followed the same logic. I translated it into a practical question: how much does each channel leave the business after its own costs?

I split marketing into two parts. The cost of acquiring orders was deducted within the economics of the relevant channel, together with commissions, delivery, and the cost of goods sold.

I then combined the contribution from all channels. From that total, I deducted labor, marketing production and maintenance costs, software, banking services, and the other expenses required to run the company.

┌────────────────────────────────────────────────┐
│                FOR EACH CHANNEL                │
│                                                │
│                    Revenue                     │
│              − order acquisition               │
│                 − commissions                  │
│                  − delivery                    │
│             − cost of goods sold               │
│             = channel contribution             │
└────────────────────────────────────────────────┘
                        │
                 combine channels
                        │
                        ▼
┌────────────────────────────────────────────────┐
│          TOTAL CHANNEL CONTRIBUTION            │
└────────────────────────────────────────────────┘
                        │
              − operating expenses
                     − taxes
                        │
                        ▼
┌────────────────────────────────────────────────┐
│             MANAGEMENT P&L RESULT              │
└────────────────────────────────────────────────┘

FOR EACH CHANNEL
Revenue
− order acquisition
− commissions
− delivery
− cost of goods sold
= channel contribution
          ↓
   COMBINE CHANNELS
          ↓
TOTAL CHANNEL CONTRIBUTION
− operating expenses
− taxes
          ↓
 MANAGEMENT P&L RESULT

This was a management P&L and cash-flow model. Taxes were included as a separate line and capital expenditure in cash flow. Balance-sheet accounting and depreciation were outside its scope, so the endpoint was a management result rather than statutory net income.

This logic became the basis of the second model. Channel-specific costs and company-wide expenses were no longer mixed together. Ingredients and packaging that had been purchased but not yet used remained in inventory for future sales. I also added accounts receivable and accounts payable to the model.

I then tested whether the calculated result could explain the change in cash after accounting for inventory, receivables, payables, and other movements. The numbers still did not reconcile. The problem was therefore not limited to how we classified costs.

Why the numbers still did not reconcile

The answer was in the marketplace reports. Their aggregate totals looked convincing, but they could not be used as a ready-made view of channel economics.

One marketplace order produced several financial transactions. Revenue was recognized only after the customer received the product. Commission, outbound and return logistics, storage, payment processing fees, advertising, compensation, returns, and disposal were recorded separately. Some costs existed at order level, some at SKU or campaign level, and some applied to the entire marketplace store.

When we assembled a total from several reports, transactions connected to the same order could land in different periods or categories. The result looked plausible but did not represent the real economics.

I therefore reversed the calculation and started from the individual order.

Bottom-up: calculating from every order

I built n8n workflows that retrieved marketplace data through APIs or parsed exported CSV and Excel reports. Every source was normalized into one structure.

One order could correspond to several financial rows. I joined them to calculate the economics of that individual order:

recognized revenue;
commission and payment processing fees;
outbound and return logistics;
storage and handling;
returns, write-offs, and disposal;
advertising costs when they could be attributed to a SKU;
cost of goods sold.

When an advertising expense was available only at SKU level, I distributed it across the units of that SKU that had been sold. Some expenses applied to the entire marketplace store rather than to a particular order—for example, a fixed fee for additional marketplace services. I kept those as shared monthly lines.

If a customer did not collect an order, there was no revenue or commission. The model still captured the costs that had occurred: logistics in both directions, storage, and disposal.

The cost of goods depended on the production period. For historical data, I used FIFO: products from earlier batches were treated as sold first. Given our small batches and limited shelf life, this matched the normal movement of our inventory.

Raw transactions and intermediate calculations remained in spreadsheets. Formulas and QUERY functions rolled them up into order, channel, and monthly totals, which then fed the main financial report.

Top-down: checking against cash movement

To verify the order-level calculation, I calculated the same result from the opposite direction. I took the actual change in cash balances and adjusted it for changes in inventory, accounts receivable and payable, investments, and other movements that did not flow directly through profit.

The two calculations began from different points:

BOTTOM-UP TOP-DOWN

marketplace transactions cash in bank accounts ↓ ↓ orders and products change during the period ↓ ↓ revenue and direct costs inventory, balances owed, ↓ and other movements channel economics company economics └────────── reconciliation ────────────┘

BOTTOM-UP
marketplace transactions
 ↓
orders and products
 ↓
revenue and direct costs
 ↓
channel economics
        ┐
        ├─ reconciliation
        ┘
TOP-DOWN
cash in bank accounts
 ↓
change during the period
 ↓
inventory, balances owed,
and other movements
 ↓
company economics

Across a full year, the two methods reconciled with a variance of around 1%. Starting from two independent directions confirmed that the model explained the actual movement of cash and was reliable enough for management decisions.

The decisions the new picture changed

The first numbers we could trust showed that margins had to increase and prices would need to rise in most channels.

When we relaunched sales through our own website in summer 2025, we once again charged customers for delivery. Several years earlier, we had abandoned that approach because free same-day delivery had been an important part of our offer.

A large premium retailer presented a different problem. The channel economics worked for us, but the product had become cheaper in the retailer's stores than on our own website and other marketplaces. We had gone too long without indexing the price and then could not agree on an increase large enough to close the gap. After a transition period, we had to end the relationship.

It was an unpleasant but important lesson: small, regular price adjustments work better than a rare, sharp revision after the gap has become too large to negotiate.

We later decided to close the company. Both the economics of the business and difficult market conditions contributed to that decision. A reliable P&L helped us separate the consequences of our own decisions from what was happening around us. Without it, we probably would have relied on distorted numbers for longer and lost more.

What I consider the result

The result was not a dashboard or another complicated spreadsheet.

I rebuilt the reporting several times and ultimately arrived at a system in which the financial result was assembled from real order-level transactions and checked independently against the movement of cash.

The numbers did not become more pleasant. They became reliable. We could base decisions on them, including decisions we did not want to make.

Some data was loaded and processed automatically. Individual deliveries, bank expenses, and cash expenses still required manual review. Recalculating the full accumulated period took one concentrated working session—from the beginning of one day until the following morning.

Today, I would build the next version on Postgres with daily data updates. AI agents could parse non-standard reports and prepare ambiguous transactions for human review. But the governing principle would remain the same: if the final numbers cannot be trusted, return to the individual orders and the transactions connected to them.

My role

In this project, I:

took ownership of management reporting and diagnosed the errors in the original accounting logic;
rebuilt the model several times and connected the P&L to cash movement, inventory, receivables, and payables;
separated product costs from operating expenses;
found why aggregate marketplace reports distorted the picture;
built the n8n ingestion and normalization of API and file data;
designed the order-level calculation and expense-allocation rules;
built an independent reconciliation against actual cash movement;
used the model to make decisions about pricing, channels, and delivery terms;
prepared the reporting and explanations directly for the investor.