Direct answer: A procurement master-data and data-quality page is not a line saying "put suppliers/materials into the system". The page should state: master-data domains (supplier, material, price, contract, category, organisation/cost centre, payment terms, tax code); coding/naming/classification/unit/currency/status rules; uniqueness/duplicate detection/merge; completeness/accuracy/consistency/timeliness/validity; who creates, approves and maintains (owner/steward), maker-checker; change/merge/deactivation/archive; systems/interfaces (ERP/SRM/MDM/BI) and reconciliation; permissions/audit; data-quality metrics. On the rules: MOF Internal Control Application Guideline No. 7 (Procurement) requires controls over procurement planning, requisition, supplier selection, price, contract, acceptance and payment; No. 18 (Information Systems) requires controls over system development, change, operation, security and data; No. 15 (Comprehensive Budget) covers budget preparation, execution, adjustment and assessment. This article is current to 2026-11-09 and is a summary of public rules and page method, not data-governance/IT-audit advice; company master-data policy, system configuration and data standards control.
This article is for procurement, IT, finance, internal-control, audit and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby. It covers how to write and accept a procurement master-data and data-quality page. The usual gap is "duplicate suppliers/materials, inconsistent codes, mixed units/currencies/tax codes, price/contract versions, change/merge, permissions/audit, data-quality metrics", ending with a page that only says "unified master-data management", while procurement/reconciliation/reporting cannot reconcile across systems.
First define domains and coding: supplier/material/price/contract/category/organisation/payment/tax code, with unified coding/naming/classification/unit/currency/status. Then define governance: owner/steward, create/change approval, maker-checker, duplicate detection/merge, permissions/audit. Finally measure quality: completeness/accuracy/consistency/timeliness/validity, system reconciliation and metrics. "Unified management" is not enough.
How does this page relate to supplier master-data/account change, information security, category/spend, budget and contract pages?
The master-data/quality page answers "where data comes from, who maintains it, how to code/merge, how to measure quality"; the supplier master-data/account-change page answers "name/tax ID/bank/call-back verification/effectiveness"; the information-security page answers "classification/access/incidents/return"; the category/spend page answers "category tree/spend analysis"; the budget page answers "limit/encumbrance/execution"; the contract page answers "clauses/signing/versions". Master data is the "common language" of procurement/finance/reporting and cannot be replaced by an account-change or information-security page.
Common breaks: duplicate/alias suppliers; one material with multiple codes or one code for multiple materials; mixed units/currencies/tax codes; unclear price/contract versions; wrong category/cost-centre mapping; no create/change approval; merge without records; unclear deactivation/archive; ERP/SRM/BI out of sync; missing permissions/audit; no data-quality metrics. The page separates "domain—coding—governance—quality—change—system—public boundary" so procurement/IT/finance/internal-control/audit share one vocabulary.
| Page | Question it answers | Key content | Cannot replace |
|---|---|---|---|
| Master data/quality | Where data comes from/who maintains/coding/quality | Domains, coding, governance, quality, change, systems | Account change/info security |
| Supplier master/account | Name/tax ID/bank/call-back/effectiveness | Account change, verification, effectiveness | Material/price/contract |
| Information security | Classification/access/incidents/return | Classification, permissions, incidents | Data quality |
| Category/spend | Category tree/spend analysis | Category, spend, savings | Master-data coding |
| Budget | Limit/encumbrance/execution | Budget, encumbrance, variance | Master data |
| Contract | Clauses/signing/versions | Price, payment, breach | Data standards |
Page relationships are editorial; company master-data policy, system configuration and data standards control.
What procurement master-data domains exist, and how should coding be set?
At least: supplier (name/unified social credit code/tax ID/bank/contacts/qualification/status); material (code/name/spec/material/unit/drawing/version/BOM/alternatives/status); price (price list/contract price/tiered price/currency/VAT/tax rate/validity/supplier/material); contract (number/supplier/material/price/payment term/validity/version); category (tree/code/owner); organisation/cost centre/project; payment terms/tax code/currency/unit. Codes must be unique, stable and extensible, without variable attributes (price/supplier name/year); naming/classification/unit/currency/tax code unified; status (draft/effective/inactive/archived) clear. Master data is not "change at will"; it needs standards and approval.
Acceptance checks: domain list; coding rules; naming/classification; unit/currency/tax code; status; uniqueness; extensibility; standards/approval. Common gaps: code contains variable attributes; one material multiple codes; supplier aliases; mixed units/currencies/tax codes; unclear status; no standard.
| Domain | What to write | Evidence | Common gap |
|---|---|---|---|
| Supplier | Name/credit code/tax ID/bank/contacts/qualification/status | Master data | Duplicate/alias |
| Material | Code/spec/material/unit/drawing/version/BOM/alternatives | Master/BOM | Multiple codes |
| Price | List/contract/tiered/currency/VAT/rate/validity | Price list/contract | Version unclear |
| Contract | Number/supplier/material/price/payment/validity/version | Contract | Version unclear |
| Category | Tree/code/owner | Category tree | Wrong mapping |
| Organisation/cost centre | Company/plant/department/cost centre/project | Org table | Wrong mapping |
| Payment/tax/currency/unit | Terms/tax code/currency/unit | Master data | Mixed |
| Coding rules | Unique/stable/extensible/no variable attributes | Standard | Price/year embedded |
Master-data domains/coding are editorial; company master-data standards and system configuration control.
How should data quality be measured and accepted?
Dimensions: completeness (required/linked fields), accuracy (consistent with contract/invoice/customs/bank), uniqueness (no duplicate supplier/material/contract), consistency (ERP/SRM/BI/finance same basis), timeliness (create/change/deactivate speed), validity (code/tax ID/bank/qualification valid). Methods: data profiling, duplicate detection, sample checks, cross-system reconciliation, issue log, fix/recheck; metrics: duplicate rate, missing rate, error rate, timeliness, cross-system variance, issue closure rate. Data quality is not "IT alone"; procurement/finance/IT/internal-control jointly set standards/metrics.
Acceptance checks: dimensions; methods; sampling; cross-system; issue log; metrics; fix/recheck; owner. Common gaps: required fields only; no duplicate check; no cross-system; no log; no metrics; no fix.
| Dimension | What to check | Evidence | Common gap |
|---|---|---|---|
| Completeness | Required/linked fields | Profiling | Required only |
| Accuracy | Contract/invoice/customs/bank consistency | Sample | No check |
| Uniqueness | No duplicate supplier/material/contract | Duplicate detection | No check |
| Consistency | ERP/SRM/BI/finance same basis | Reconciliation | Different systems |
| Timeliness | Create/change/deactivate speed | Log | Never updated |
| Validity | Code/tax ID/bank/qualification valid | Verification | Expired |
| Issue log | Detect/owner/fix/recheck | Log | No log |
| Metrics | Duplicate/missing/error/timeliness/variance/closure | Report | No metrics |
Data quality is editorial; company data standards, systems and audit requirements control.
How should governance, change and merge be accepted?
Governance: owner (domain)/steward (data administrator); create/change request, approval, maker-checker; least privilege; audit log; source of truth; interfaces/sync between master data and ERP/SRM/MDM/BI. Change: supplier name/tax ID/bank (call-back verification), material spec/alternative/EOL, price/contract version, category/cost centre, status (inactive/archived). Merge: duplicate detection, merge rules, impact assessment (orders/contracts/invoices/inventory/reports), approval, retain history/audit; do not delete directly. Deactivation/archive: stop new transactions, clear open items, retain history, revoke access.
Acceptance checks: owner/steward; request/approval; maker-checker; permissions; audit; source system; interfaces; change types; merge rules/impact; deactivation/archive. Common gaps: no owner; no approval; one-person change; no log; multiple sources; direct delete on merge; open items not cleared.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Owner/steward | Domain owner/data administrator | Appointment | No owner |
| Request/approval | Create/change/deactivate approval | Process | No approval |
| Maker-checker | Entry/review separation | Record | One-person change |
| Permissions/audit | Least privilege, log | System | No log |
| Source/interfaces | Source of truth, sync/reconciliation | System | Multiple sources |
| Change types | Supplier/material/price/contract/category | Record | Unclear |
| Merge | Detection/rules/impact/approval/history | Record | Direct delete |
| Deactivation/archive | Stop new/clear open/history/access | Record | Open items |
Governance/change is editorial; company master-data policy, permissions and audit requirements control.
How should systems/interfaces and reconciliation be accepted?
Systems: ERP (procurement/inventory/finance), SRM (supplier/RFQ/order), MDM (master data), BI/reporting, contract/invoice/bank systems; state source of truth, ID mapping, interface direction/frequency, error handling, retry/compensation, permissions. Reconciliation: supplier/material/price/contract quantities/amounts/status consistent across ERP/SRM/BI/finance; interface failure/duplicate/loss alerts/compensation; change-sync timeliness; reporting basis consistent. Do not have "one set per system", and do not treat "interface ran successfully" as "data correct".
Acceptance checks: system list; source of truth; ID mapping; interface direction/frequency; error/retry; permissions; reconciliation; alerts; basis. Common gaps: multiple sources; no ID mapping; no interface monitoring; no backfill; different reporting basis.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| System list | ERP/SRM/MDM/BI/contract/invoice/bank | List | Incomplete |
| Source of truth | Primary source per domain | Policy | Multiple sources |
| ID mapping | Supplier/material/contract ID | Mapping table | No mapping |
| Interface | Direction/frequency/fields/errors | Interface doc | No doc |
| Retry/compensation | Failure alert/retry/backfill | Log | No backfill |
| Permissions | Least privilege/audit | System | Too broad |
| Reconciliation | Quantity/amount/status consistent | Reconciliation | Inconsistent |
| Basis | Reporting basis consistent | Basis note | Different |
Systems/interfaces are editorial; company IT architecture, master-data policy and interface specs control.
How should the website page be written, and what must not be published?
Suggested sections: (1) master-data domains/coding principles; (2) data-quality dimensions/metrics; (3) governance/change/merge; (4) systems/interfaces/reconciliation; (5) contact/update date. The public page explains "domains, standards, governance, quality, boundaries" and does not publish supplier names/tax IDs/bank accounts, materials/BOM/prices/contracts, system screenshots, interface addresses/accounts, data-quality issue details or pending disputes; specifics are handled in master-data/ERP/BI controlled systems. Do not claim "100% accurate/no duplicates/real-time sync" if you cannot prove it; do not turn the master-data page into a public supplier directory.
The English page should use consistent terms (master data, data quality, data owner/steward, source of truth, duplicate/merge, completeness/accuracy/uniqueness/consistency/timeliness/validity, ERP/SRM/MDM/BI, interface/reconciliation) and state the cut-off date. It can link to supplier master-data/account, information-security, category/spend, budget and contract pages, but must not become a "unified management" line.
| Section | What to write | Evidence | Avoid |
|---|---|---|---|
| Domains/coding | Supplier/material/price/contract/category | Standard | Code with variable attributes |
| Quality | Completeness/accuracy/uniqueness/consistency/timeliness/validity | Metrics/log | Required only |
| Governance | Owner/steward/approval/maker-checker | Process | One-person change |
| Change/merge | Detection/rules/impact/history | Record | Direct delete |
| Systems/reconciliation | Source/interface/alert/basis | System | Multiple sources |
| Public boundary | No suppliers/prices/systems | Permissions | Publish all |
The page structure is editorial; public statements must be true and verifiable, and company master-data policy, system configuration and data standards control.
Go-live acceptance checklist
Ten checks: domains/coding; naming/classification/unit/currency/tax code; uniqueness/duplicate detection; quality dimensions/metrics; owner/steward/approval; maker-checker/permissions/audit; change/merge/deactivation; systems/interfaces/reconciliation; issue log/fix; public boundary. Each needs evidence and a review date. The pass standard is not "the page says unified management", but that procurement/IT/finance/internal-control/audit can judge where data comes from, who maintains it, how to code/merge, how to measure quality and how systems reconcile.
Before go-live, run a tabletop exercise with a real (redacted) supplier/material: create → code → approve → enter → price/contract → change → merge → deactivate → reconcile. Then simulate "duplicate supplier", "one material multiple codes", "mixed unit/currency" and "interface failure without backfill" to see whether the page and process work.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Domains/coding | Supplier/material/price/contract/category | Standard | Add standard |
| Naming/classification/unit | Naming/classification/unit/currency/tax code unified | Master data | Add rules |
| Uniqueness/duplicate | Duplicate detection/merge rules | Record | De-duplicate |
| Quality/metrics | Completeness/accuracy/consistency/timeliness/validity | Report | Add metrics |
| Owner/approval | Owner/steward/approval | Appointment/process | Add governance |
| Maker-checker | Entry/review separation, permissions, log | System | Add controls |
| Change/merge/deactivate | Impact/approval/history/open items | Record | Add process |
| Systems/reconciliation | Source/interface/alert/basis | Reconciliation | Reconcile |
| Issue log | Detect/owner/fix/recheck | Log | Add log |
| Public boundary | No suppliers/prices/systems | Page/permissions | Take down |
The acceptance list is editorial; company master-data policy, system configuration and audit requirements control.
Who should read it, who should not, and what decisions does it support?
For procurement, IT, finance, internal-control, audit and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies handling "duplicate suppliers, one material multiple codes, mixed units/currencies/tax codes, price/contract versions, change/merge, system out of sync, no data-quality metrics". Not for teams that do not involve procurement master data/systems, or that want one page to replace data-governance/IT-audit advice.
Read it if: building a master-data/quality page; only "unified management"; duplicate suppliers; one material multiple codes; mixed units/currencies/tax codes; unclear price/contract versions; no owner/approval; direct delete on merge; system out of sync; no quality metrics. Not suitable if: treating "master data" as "supplier directory"; treating "interface success" as "data correct"; treating "merge" as "delete"; treating "quality" as "required fields". Supports: domains/coding, quality dimensions, governance/change, systems/reconciliation and public-boundary self-checks.
FAQ
Which procurement master-data domains are there?
At least supplier, material, price, contract, category, organisation/cost centre/project, payment terms, tax code, currency/unit. Each domain needs coding/naming/classification/unit/currency/status rules, owner/steward, create/change approval, uniqueness/duplicate detection, quality metrics and a system source of truth; master data is not a "supplier directory" or an "ERP field".
What should we do about duplicate suppliers/materials?
First detect (name/credit code/tax ID/bank/address/contact; material spec/drawing/unit/material), then assess impact (orders/contracts/invoices/inventory/reports), merge under rules (keep master record, map old IDs, migrate links, retain history/audit), approve and execute; do not delete directly. After merge, update interfaces/reports/permissions and recheck the duplicate rate. Company master-data policy and system capability control.
How should data-quality metrics be set?
Common: completeness (required/linked field missing rate), accuracy (consistency with contract/invoice/customs/bank), uniqueness (supplier/material/contract duplicate rate), consistency (ERP/SRM/BI/finance variance), timeliness (create/change/deactivate), validity (code/tax ID/bank/qualification expiry), issue closure rate. Metrics need definition, sample, period, target and owner; do not assess only "required-field rate".
Do master-data changes/merges need approval?
Yes. Create/change/deactivate/merge should have request, approval, maker-checker, least privilege and audit log; supplier name/tax ID/bank changes require call-back verification (see the account-change page); material spec/alternative/EOL and price/contract version changes need impact assessment; merge should retain history/mapping/audit. One-person direct change, direct delete and no log are high-risk.
How should ERP/SRM/MDM/BI reconcile?
First define the source of truth per domain, then ID mapping/interface direction/frequency/error handling/retry compensation; reconcile supplier/material/price/contract quantities/amounts/status and reporting basis; interface success is not data correctness — add alerts/backfill/sample checks. Multiple sources, no mapping, no monitoring and no backfill cause procurement/finance/reporting to disagree.
How does master data relate to the information-security page?
The master-data page covers "data standards/quality/governance/change/systems"; the information-security page covers "classification/access/transmission/incidents/return/cross-border"; they complement each other. Master data should be authorised by information-security classification with least privilege and logs/audit; sensitive supplier bank/price/contract data must be controlled and not published on the website. Do not replace master-data standards with the security page, or security controls with the master-data page.
Should the website publish supplier directories, materials and prices?
Usually not supplier names/tax IDs/bank accounts, materials/BOM/prices/contracts, system screenshots, interface addresses/accounts, data-quality issue details or pending disputes. The public page can explain master-data domains/coding principles, quality dimensions/metrics, governance/change/merge, systems/reconciliation and a contact window; specifics are handled in master-data/ERP/BI controlled systems. Do not claim "100% accurate/no duplicates/real-time sync" if you cannot prove it.
One-sentence takeaway
The procurement master-data and data-quality page on a Changzhou manufacturer's website is not about "unified management"; it is about turning master-data domains/coding, naming/classification/unit/currency/tax code, uniqueness/duplicate detection, quality dimensions/metrics, owner/steward/approval, maker-checker/permissions/audit, change/merge/deactivation, systems/interfaces/reconciliation, issue log and public boundaries into a checkable list, so procurement/IT/finance/internal-control/audit can judge where data comes from, who maintains it, how to code/merge, how to measure quality and how systems reconcile.
Research method and limitations
This article is a summary of public rules and page method, not data-governance or IT-audit advice. It uses no unpublished supplier/material/price/contract data, system screenshots, interface addresses/accounts, data-quality issue details or pending disputes; the tables and acceptance items are editorial and not data-governance/audit conclusions. MOF Internal Control Application Guideline No. 7 (Procurement), No. 18 (Information Systems) and No. 15 (Comprehensive Budget); company master-data policy, system configuration, data standards and audit requirements control. This article does not decide whether any specific master-data/quality metric is reasonable, and does not promise 100% accuracy/no duplicates/real-time sync; companies should set them item by item based on systems, domains and data.
Sources and basis
Current to 2026-11-09; the official pages below control.
- MOF Internal Control Application Guideline No. 7 — Procurement (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Procurement planning, requisition, supplier selection, price, contract, acceptance and payment.
- MOF Internal Control Application Guideline No. 18 — Information Systems (Cai Kuai [2010] No. 11): Linyi Finance Bureau. System development, change, operation, security and data controls.
- MOF Internal Control Application Guideline No. 15 — Comprehensive Budget (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Budget preparation, execution, adjustment and assessment.