Multi-Entity Operations at Enterprise Scale - One Platform, Any Number of Entities

A multi-entity business is not simply a larger version of a single-entity business. The operational complexity doesn't scale linearly - it compounds at the boundaries between entities. Each entity may have separate financial rails, separate payment processors, separate regulatory obligations, different staff access requirements, and different operational rhythms. The data that belongs to one entity should not be visible to or modifiable by operations scoped to the other.

Most software treats this as a configuration problem. Add a "company" field. Filter everything by it. Apply a label to records so they can be separated in reports. This approach works until it doesn't - until you need separate Xero organisations with their own invoice sequences and financial reporting, separate Ezidebit accounts with independent collection schedules, and RBAC that actually enforces entity boundaries rather than just displaying them.

Petriko treats multi-entity as a first-class architectural concern, not a filter applied on top of a single-entity model. The difference is significant, and it's visible in every part of the system.

Entity-Scoped Data, Entity-Routed Integrations

In Petriko, every data record that carries operational significance is scoped to an entity at the data layer. Fleet records, customer records, subscription contracts, job cards, payment records - all carry entity attribution that is enforced structurally, not through UI filtering.

The entity switcher in the navigation bar moves the operational view between franchise entities without a separate login. What you see when operating in one entity context is correctly scoped to that entity - not a filtered view of a combined dataset where an incorrect filter could expose the wrong data, but a structurally scoped view where the entity boundary is enforced at the query level.

More significantly: financial events are routed to the correct external system automatically. When a subscription in Entity A activates, the resulting Xero invoice goes to Entity A's Xero organisation, and the Ezidebit collection schedule is established in Entity A's Ezidebit account. No manual routing decision is required. The entity attribution on the subscription record determines where the financial event goes.

This is the meaningful difference between treating multi-entity as a filter and treating it as architecture. A filter is applied after the data model has already ignored the boundary. An architectural boundary means the boundary is enforced before the data ever reaches the financial systems - at the point of origin.

RBAC Across Entities

Staff access in a multi-entity business is not binary - it's not "has access" or "doesn't have access." The meaningful questions are: which modules, which actions, and which entities?

Petriko's RBAC model applies five permission levels - View, Create, Edit, Delete, and Approve - independently to each operational module. This already provides granular control within a single entity. Across entities, the model adds entity scope: staff can be provisioned with access to both entities, one entity only, or specific modules within each entity.

An operations manager might have full operational access to both entities. A finance officer might have payment visibility across entities but no fleet write access. A workshop mechanic might be scoped entirely to one entity's job cards. These configurations are expressed precisely in the permission matrix - not approximated through role naming conventions or manual workarounds.

Staff provisioned for one entity cannot see the other entity's data - not because a filter is applied to their view, but because the entity boundary is enforced at the data access layer. The security model holds even if the UI filter were removed, because the enforcement is architectural.

Scale Is Configuration, Not Deployment

Adding a third entity to a Petriko deployment is a configuration operation. A new entity record is created, Xero and Ezidebit credentials are connected, and the entity becomes available for data attribution and staff scope assignment. No new deployment is required. No code changes are needed. The architecture assumed multi-entity from the start, so adding a new entity is simply extending the existing model.

This applies equally to any recurring-revenue business operating across multiple sites, locations, or legal entities on Xero and Ezidebit. The fleet subscription vertical is the first production use case, but the architectural pattern - entity-scoped operational data, entity-routed financial integrations, entity-aware RBAC - applies to any operator in that structural position.

The common alternative is to run separate software instances for each entity and manage the resulting operational fragmentation manually. That approach has a cost: separate logins, separate data sets that can't be viewed together, and a cross-entity operational picture that exists only in someone's head or in a manual consolidation exercise. Petriko's architecture makes the cross-entity view available without compromising the entity boundary.

Built for How Multi-Entity Businesses Actually Operate

The operational reality of a multi-entity business is that the people managing it operate across entity boundaries constantly - but the data and financial systems need to stay separated. A manager needs to see both entities at once to make operational decisions. The accounting and payment systems need to stay attributed correctly to each.

Petriko holds both of these requirements simultaneously. The operational view can span entities. The financial routing is always entity-correct. RBAC enforces who can see and do what, at which entity. Staff log in once and operate in the context that's appropriate for what they're doing.

Multi-entity operations at scale require software that was designed for multi-entity from the ground up. When entity scope is architectural rather than a filter, the business can grow without the operational infrastructure becoming the constraint.