Pronto Xi Master Data Governance: Who Owns Customers, Suppliers, Products and Pricing?
A practical operating model for Pronto Xi master data governance, covering who owns customers, suppliers, products and pricing, which controls to apply and how to measure the return.
Pronto Xi master data should be owned by the business leaders accountable for the decisions it supports. Sales or commercial teams generally own customer relationships and pricing policy; finance owns credit and payment controls; procurement owns supplier relationships; and operations or product management owns product definitions. Named stewards maintain the records, while IT supports the systems and controls.
For CFOs, CIOs and IT leaders, the investment question is practical: which data problems are causing avoidable cost or risk, and what ownership, rules and controls will address them?
This article provides a recommended operating model. Product statements are sourced; proposed controls must be validated against your Pronto Xi version, modules, permissions and integrations. The worked example is hypothetical.
Who owns what? A practical responsibility matrix
Assign one accountable owner to each field group. Separate the authority to approve a change from the responsibility to enter it.
| Data or decision | Accountable owner | Required approval | Implements | Consulted |
|---|---|---|---|---|
| Customer identity, contacts and commercial grouping | Commercial lead | Commercial delegate; finance concurrence for billing identity or account-structure changes | Customer-data steward | Finance, sales |
| Credit limits, terms and account restrictions | Finance lead | Credit-control delegate within documented limits | Finance steward | Sales |
| Supplier identity, sourcing and trading status | Procurement lead | Procurement delegate; finance concurrence for payment activation | Supplier-data steward | Accounts payable, operations |
| Supplier bank details and payment settings | Finance lead | Independent finance approver after verification | Authorised finance steward | Procurement |
| Product descriptions and classification | Product or operations lead | Product-data delegate | Product-data steward | Sales, purchasing, reporting users |
| Units, pack sizes and operational attributes | Operations lead | Operations delegate; affected field owners approve linked changes | Product-data steward | Warehouse, procurement, manufacturing where relevant |
| Product accounting and tax settings | Finance lead | Finance delegate with appropriate expertise | Authorised steward | Operations, relevant specialists |
| Selling-price rules and promotions | Commercial lead | Pricing delegate; finance approval for defined policy exceptions | Pricing steward | Sales, affected channels |
| Permissions and technical update mechanisms | IT or ERP service owner | Technical authority plus business-owner approval of access purpose and data rules | Authorised technical operator | Relevant data stewards |
This is a starting model, not a universal organisation chart. Replace roles with names, deputies and delegated limits. A consulted person provides input; a required approver must authorise the relevant decision.
For each change category, also name a verifier. High-risk changes should have verification independent of the implementer wherever practicable.
Appoint an owner for the whole record lifecycle
Field ownership needs coordination. Assign one lifecycle owner for each domain, customers, suppliers and products, to coordinate creation, activation, restriction and retirement.
The lifecycle owner confirms that required field approvals and checks are complete. They do not override another owner's authority over credit, payment or accounting decisions.
Name an executive escalation owner for cross-functional disagreements and set a decision deadline. Record unresolved requests as pending; silence should not count as approval.
What is master data, and why does its quality matter?
Master data describes the entities reused in business transactions: customers, suppliers and products, together with their commercial and operational attributes.
An invoice is a transaction. The customer identity and payment terms used to process it are master data.
Pricing needs related governance because the selling price may depend on price lists, customer agreements, promotions, discounts and transaction overrides. These decisions may not all reside in one record.
Pronto Software describes its Distribution applications as covering inventory, detailed pricing information and the sales order lifecycle.[1] Changes to underlying records can therefore matter beyond the screen on which they are entered.
Examples of problems worth investigating include:
- Duplicate customer accounts that fragment credit review.
- Incorrect supplier details that create payment exceptions.
- Wrong product conversions that affect purchasing or fulfilment.
- Conflicting price rules that produce incorrect selling prices.
- Interfaces that overwrite an approved correction.
Establish the actual cause before attributing an incident to master data.
Which master data problem should you fix first?
Select a manageable pilot using five questions:
| Question | Evidence to review |
|---|---|
| What could the problem cost or disrupt? | Verified financial impact, operational exposure and affected controls |
| How frequently does it occur? | Incident history and affected transaction volumes |
| How weak are the current controls? | Missing approvals, excessive access or unmonitored update paths |
| What would improvement require? | Investigation, cleanup, configuration, training and ongoing effort |
| Can the result be measured? | Available baseline, data source and accountable benefit owner |
High-impact, infrequent risks may justify action even without a large incident count. Avoid choosing the pilot solely because the data is easy to clean.
Before approving a wider programme, require six pilot deliverables: an accountable owner, critical data rules, an approval route, a tested control, an exception process and a baseline measure.
Define what good data looks like
Approval is not proof of data quality. A correctly authorised record can still be incomplete, duplicated or inconsistent.
Agree rules for the fields that matter to the process, including what evidence establishes accuracy.
| Data group | Illustrative quality rule | Check before activation or change |
|---|---|---|
| Customer | Billing identity and account relationships are verified | Confirm the intended entity, addresses and account structure |
| Supplier | Potential duplicates are investigated | Compare identifiers and legitimate branch, entity or account arrangements |
| Product | Required units and conversion factors support intended transactions | Test relevant purchase, receipt and sale quantities |
| Pricing | Eligibility, dates and precedence are explicit | Test overlapping rules and boundary dates |
| Shared identifiers | Connected systems refer to the correct entity | Validate mappings and reconcile sample records |
A matching name, ABN or bank account can justify investigation; it does not by itself prove that two records should be merged.
Record the rule owner, validation method, permitted exceptions and review frequency. Review inactive records and recurring exceptions as well as newly created data.
Separate preventive, detective and corrective controls
These controls perform different jobs.
| Control type | Purpose | Example requirement |
|---|---|---|
| Preventive | Stop an unauthorised or invalid change before it becomes operational | Restrict sensitive updates to authorised operators following required approval |
| Detective | Identify an incorrect or unauthorised change after it occurs | Reconcile actual changes to approved requests |
| Corrective | Restore the approved state and address the consequences | Correct the record, assess affected transactions and verify downstream recovery |
An approval ticket establishes a decision record. It does not, by itself, prevent someone from changing Pronto Xi.
A review after implementation is a detective control. It does not provide the same protection as blocking an unapproved update before activation.
Where a technical restriction is unavailable, document the procedural alternative, how quickly exceptions will be detected, the exposure before detection and who accepts that residual risk. The accountable business owner should accept risk within their authority; larger exposures need executive escalation.
Small teams can combine responsibilities, but should explicitly manage conflicts rather than assume a later review removes them.
Build an approval workflow that people can use
Apply stronger controls to supplier bank changes, sensitive financial attributes and broad price updates than to low-impact descriptive edits.
| Stage | Decision or action | Evidence |
|---|---|---|
| Request | Identify the record, proposed change, reason and effective date | Request ID, requester, current/proposed values and support |
| Validate | Check data rules, duplicates, dependencies and risk category | Validation result and unresolved questions |
| Approve | Obtain each required approval within delegated authority | Approver, conditions and timestamp |
| Implement | Apply the approved change through an authorised method | Operator, affected records and before/after evidence |
| Verify | Check the stored value and relevant downstream outcomes | Verifier and test or reconciliation result |
| Close | Confirm completion or assign remaining exceptions | Closure decision, exception owner and deadline |
Rejected or incomplete requests return for correction. Emergency changes need defined authority, recorded justification and prompt review.
For supplier bank-detail changes, independently verify the request using a known, verified telephone number. The Australian Cyber Security Centre advises against relying on a number supplied in the change-request email.[3] Keep approval to change the supplier record separate from approval to release a payment.
Retain change evidence under your recordkeeping policy, with sensitive information protected.
Govern every route into Pronto Xi
Cover screen entry, bulk uploads, interfaces, scheduled jobs and privileged maintenance in the control assessment.
For each data group, document:
- The authoritative source and permitted update direction.
- The identifiers used to match records.
- Who may update it, including service accounts.
- How invalid, duplicate or conflicting updates are handled.
- How publication failures are detected and reconciled.
- Who owns recovery and confirms completion.
Pronto Software documents Pronto Connect as a platform for integrating external applications with Pronto Xi.[2] Validate the approval, reconciliation and recovery behaviour of each actual interface.
Ask your Pronto team to demonstrate unauthorised update attempts, bulk-file validation, available change history and downstream reconciliation. Record gaps where the system cannot enforce a required rule.
A last-modified timestamp alone does not establish who approved a change or what the previous value was.
Worked example: a promotion that fails to reach the online channel
The following scenario and prices are hypothetical. The controls are proposed requirements, not claims about standard Pronto functionality.
A distributor approves a price of AUD $90 per item, excluding GST, for Product P100 and eligible customers during an agreed promotion period. The normal price is $100.
For this example, the approved policy requires the same promotional price in Pronto and the online channel. Both are to be verified before launch; channels that cannot be verified must not continue taking affected promotional orders until an authorised decision is made.
Establish the decision rights
| Responsibility | Assigned role in this example |
|---|---|
| Approve eligibility, dates and price | Commercial owner |
| Approve any margin-policy exception | Finance delegate |
| Implement the approved price | Pricing steward |
| Monitor publication and lead technical recovery | Integration support owner |
| Verify the customer-facing result | Online-channel owner |
| Decide whether to pause, withdraw or approve a limited launch | Commercial owner within delegation, with other required approvals |
The request must also define treatment of existing orders, competing price rules, returns and publication delays.
Test normal operation and failures
| Scenario | Required outcome |
|---|---|
| Eligible customer orders during the promotion | Approved $90 unit price applies |
| Ineligible customer orders | Normal $100 price applies in this isolated scenario |
| Promotion ends | The approved post-promotion price applies |
| Unapproved price is submitted through an import | The proposed preventive control rejects or holds it; a warning after activation does not pass this test |
| An interface attempts to overwrite the approved price | The update is rejected or quarantined where prevention is required; any actual control gap is recorded |
| Online publication fails | An exception is raised, an owner is assigned and the launch or affected order-taking is paused under the agreed policy |
| A failed publication is retried | Retry produces the intended result without duplicate or conflicting records |
| The promotion must be withdrawn | The authorised price is restored, affected orders are assessed and all relevant channels are rechecked |
If Pronto shows $90 while the online channel still shows $100, the change is incomplete.
Support investigates and restores publication. The commercial owner decides how to handle any affected orders under the organisation's policies, involving other authorised functions as needed. Closure requires recorded confirmation that both the source and customer-facing result are correct.
This example exposes an essential distinction: technical recovery and the commercial decision about affected customers have different owners.
Control retirement and bulk changes
Before disabling, merging or retiring a record, check open orders, balances, stock, history, reporting and interfaces. Obtain affected owners' approval and use a supported method that preserves necessary history.
For bulk changes, retain the approved file or version, reconcile accepted and rejected rows, test representative results and define recovery before implementation.
Changing a unit conversion or price does not establish what will happen to existing transactions. Validate that behaviour before release.
Measure business results and control coverage
Use a small set of clearly defined measures.
| Measure | How to use it |
|---|---|
| Approval coverage | Required approval evidence for actual in-scope changes reviewed |
| Data-quality failures | Records failing specified rules, divided by the population assessed |
| Correction effort | Logged time resolving confirmed master-data issues |
| Pricing impact | Verified underbilling, margin effects and recovery, analysed separately |
| Turnaround time | Median and longer-running requests by risk category |
| Publication reliability | Approved updates reconciled across required systems within the agreed period |
For approval coverage, define the period, update routes and sampling method. Compare actual changes with requests. Reviewing only completed tickets can miss changes made outside the process. If the change population is incomplete, report that limitation.
Do not treat the face value of every credit note as an economic loss. A credit may reverse an overcharge. Separate correction effort, verified underbilling or margin loss, collection delays and control failures.
Time released becomes a cash saving only when expenditure changes. Report additional capacity separately. Keep risk reduction distinct from realised savings, and avoid double counting benefits.
Compare results with setup and ongoing costs: analysis, cleansing, configuration, integration, training, stewardship and monitoring. Assign a benefit owner and review date.
Start with one controlled pilot
A suggested first-month sequence is:
- Define the problem: select one domain or change category and establish the baseline.
- Assign authority: name owners, delegates, verifiers and an escalation route.
- Specify and test: agree critical rules and test normal, rejected and failed changes.
- Review performance: assess evidence, turnaround time, exceptions and operating effort before expanding.
Adjust timing to the environment. Proceed to wider rollout when the pilot demonstrates both effective controls and a workable process.
Put the right Pronto expertise behind the operating model
Business-analysis capability helps define ownership, data rules and processes. Functional expertise validates Pronto behaviour. Technical specialists address access and interfaces, while an ERP manager coordinates ongoing priorities and service ownership.
Read SAAPRO's guide to Pronto Xi roles or Contact SAAPRO to discuss the skills needed to address your priority master-data problem.
Frequently Asked Questions
Business leaders should own the rules and decisions for their data. Finance typically owns credit and payment controls, commercial teams own customer relationships and pricing policy, and operations owns product attributes. Stewards maintain records, while a lifecycle owner coordinates activation and retirement across functions.
No. The owner is accountable for definitions, quality standards and business decisions. The steward performs maintenance and quality checks under those rules. One person may hold both responsibilities, but sensitive changes still need appropriate approval and verification arrangements.
An approval form records authorisation. Prevention depends on controls that restrict or block implementation before approval. If users or interfaces can bypass the process, additional controls are needed. A later review can detect exceptions but does not provide the same protection as prevention.
The complete control model must be assessed in your installation. Ask a Pronto specialist to demonstrate the required behaviour for your version, modules, permissions, imports and interfaces. Record any gaps and assess configuration or procedural alternatives with clear ownership of remaining risk.
Measure verified reductions in correction effort, pricing losses and transaction exceptions against implementation and operating costs. Distinguish capacity from cash savings, and risk reduction from realised benefits. Use consistent definitions, establish a baseline and assign an owner to validate the results.
Key Takeaways
- ✓Master data should be owned by the business leaders accountable for the decisions it supports. Stewards maintain the records, while IT supports the systems and controls.
- ✓Separate the authority to approve a change from the responsibility to enter it, and name an independent verifier for high-risk changes.
- ✓Approval is not proof of data quality. Agree explicit rules and evidence for the fields that matter to each process.
- ✓Preventive, detective and corrective controls do different jobs. An approval ticket records a decision but does not stop someone changing Pronto Xi.
- ✓Govern every route into Pronto Xi, including bulk uploads, interfaces, scheduled jobs and privileged maintenance, not just screen entry.
- ✓Start with one measurable pilot, and report capacity, cash savings and risk reduction separately when measuring ROI.
