Unified commerce solved the customer journey. So why did it break finance?

Key takeaways

The transaction is no longer the right unit of account

The problem starts with a persistent assumption: one order equals one financial flow.

In unified commerce, one order can involve an ecommerce channel, a franchisee, a warehouse and a different store handling the return. These actors may belong to separate legal entities and operate under different commercial arrangements. 

The organisation taking the payment may not be the one fulfilling the order. One entity may owe a commission, another may owe a delivery fee, and they may need an internal invoice. If the customer makes a partial return, those allocations may need to be recalculated without losing the original transaction history. 

The risk extends beyond reconciliation

This is not simply a question of closing the books faster. 
 

When operational activity doesn’t align with the retailer’s legal structure, the business may record revenue against the wrong entity, allocate amounts without clear justification or issue invoices that don’t reflect who made the sale. In a multi-entity organisation, even invoice numbering must be managed correctly for each entity. Gaps, overlaps or using a single sequence across several entities can create compliance problems.  
 

Electronic invoicing makes that connection more important. Retailers increasingly need to produce structured invoice data, maintain compliant records and demonstrate consistency between the commercial event and its tax treatment. Compliance cannot be a separate exercise that begins after the transaction has taken place. It must be an output of the financial model.  

Finance needs to start with events

Unified commerce platforms already record the events needed to build this model, from payment and fulfilment to delivery and returns. 
 

The opportunity is to turn that operational history into a financial record. This is the role of Planet Revenue Allocation. It takes events from Planet Unified Commerce, identifies the entities involved and applies the relevant rules for commissions, fees, internal charges and refunds. It then creates financial flows that reflect both the commercial decision and the responsible legal entity.  

That distinction matters. A return is not merely a refund. It may reverse an allocation, cancel or preserve a commission, adjust a settlement and change the amount owed between entities. The rules must therefore be explicit, versioned and capable of being recalculated. Otherwise, every exception becomes another manual intervention.  

Calculation is only the first step

Reliable financial orchestration requires continuity across three stages: preparing the financial flows, executing transfers or internal invoices, and controlling the resulting positions through reconciliation, audit and close. When each stage sits in a separate system, traceability breaks where finance needs it most.  
 

The goal is not to replace the ERP (enterprise resource planning system). It is to give it consistent financial data that already reflects the operational event, the business rule and the correct legal entity.

Unified commerce does not need another layer of retrospective reconciliation. It needs a financial architecture that follows the transaction as it happens. That is how retailers move from reconstructing financial reality after the event to creating it correctly from the start.