Master Data Management: One Source of Truth Across Fleet, Customers & Subscriptions
When customer records, asset records, and contract records live in separate systems, every business decision is made on a partial view. Petriko makes them first-class linked entities.
In most fleet operations, the customer who pays and the vehicle they drive are recorded in different places. The contract that connects them is somewhere else again. Each part of the business has a partial view of the whole - accurate within its own domain, but unaware of what's happening in adjacent ones.
This is the master data problem. When something changes in one domain - a customer updates contact details, a vehicle is reassigned, a subscription renews - the update needs to flow through to every system that depends on that information. When it doesn't, decisions get made on stale data. Teams spend time reconciling records that should have been in sync automatically.
The solution isn't to pick one system and treat it as the master while manually exporting to the others. That creates a fragile dependency on a manual process that will eventually break. The solution is to build the data model correctly from the start - treating customers, fleet assets, and contracts as first-class linked entities that reference each other structurally, not through periodic exports.
Fleet as a First-Class Entity
In Petriko, every vehicle is a complete operational entity. Its record isn't a row in a list - it's a domain object that other parts of the system reference and respond to.
A vehicle record carries: make, model, year, registration, VIN, current status, insurance state, compliance due dates (registration renewal, insurance expiry, scheduled inspection), and a complete service history. Linked to it are the chain of subscriptions that have been attached to it over time - the current subscriber if active, and the historical record of previous subscribers with the dates they held the vehicle.
The compliance view isn't a separate report - it's derived from the vehicle's structural data. When a registration due date is approaching, the compliance module knows because the date is an attribute of the vehicle entity, not a separate manual entry in a different system.
Fleet status changes are also structural events. When a vehicle moves from available to subscribed, that change is recorded against the vehicle entity and propagates to the subscription domain. When it's reassigned, the old subscription closes and a new one opens - the history stays attached to each.
Customer as a First-Class Entity
A customer record in Petriko carries the full operational profile: contact details, linked contracts and their current states, the history of vehicles held, financial state from the Xero integration, payment history from Ezidebit, notes and documents attached to the record, and a complete activity timeline.
When a customer calls, the person handling the call has the complete picture in one view. There is no need to check a separate financial system for invoice state, a separate payment system for collection history, or a separate operational record for vehicle and contract details. The information is assembled from the linked entities and presented as a unified profile.
Customer records also carry entity attribution. In a multi-entity business, a customer belongs to a specific franchise entity. Their financial records in Xero route to the correct organisation. Their Ezidebit collections are attributed to the correct account. This is structural, not a label applied after the fact.
Customer Vehicles Tab - Complete Vehicle History
The vehicles tab on a customer's profile shows every vehicle they have held - current and historical - with the subscription that linked them and the dates it was active. This is not a separate query or a manual cross-reference. It's the structural relationship between the customer entity and the subscription entities that reference it.
When a customer asks about a vehicle they held previously - when it was returned, what the service history was, whether there were any outstanding issues - the information is in their profile, linked structurally to the vehicle and subscription records.
Subscription - The Contract That Connects Everything
The subscription is the entity at the centre of the business model. It binds a customer to a vehicle with a complete audit trail, and it carries the terms of the relationship: start date, weekly or monthly amount, setup fee, payment schedule, and current status.
Lifecycle events on the subscription propagate outward. Activation creates the Xero invoice chain and the Ezidebit collection schedule. Renewal updates both. A vehicle reassignment closes the subscription attached to the old vehicle and opens a new one on the replacement - the financial and payment records update accordingly. An odometer reading logged against a subscription feeds into service interval tracking.
The subscription is not just a record of what was agreed - it's the operational event source for the financial and payment systems.
The Business Case for Correct Data Architecture
Master data management has a direct operational value: when records are correct and consistent, the decisions made from them are reliable. When they're not, decisions are made on partial information - and the cost of that is harder to see than the cost of a system investment, but it's real and it compounds.
When fleet, customer, and contract records are first-class linked entities from the start, the business operates from a single source of truth. Not because someone maintains it manually, but because the architecture enforces it structurally. Changes propagate. History is preserved. The data reflects the business as it actually is, not as it was the last time someone ran a reconciliation.
That's what master data management means in practice - not a software feature, but an architectural decision about where truth lives and how it flows.