Procurement Authorization and Approval-Authority Matrix Pages on Changzhou Manufacturer Websites: How Should They Be Accepted?

Direct answer: A procurement authorization and approval-authority matrix page is not a line saying "approved according to authority". The page should state: authority levels (board/management/procurement/finance/requester); dimensions (amount, category risk, capital vs expense, contract type, sole source, emergency, related-party); thresholds and escalation; delegation, acting authority and temporary authority; segregation of duties (requisition/approval, RFQ/supplier selection, contract drafting/review, purchasing/acceptance, payment approval/payment execution); system permissions and over-limit blocking; change, revocation and annual review; audit trail. On the rules: MOF Internal Control Application Guideline No. 7 (Procurement) requires duties and approval authority to be defined for requisition, approval, purchasing, acceptance, payment and post-purchase review; No. 6 (Fund Activities) requires authorization, approval and verification systems, defined duties and segregation, and prohibits one person from handling the whole cash process; No. 18 (Information Systems) covers system development, change, operation, security and data controls. The Basic Standard for Enterprise Internal Control applies to listed companies from 1 July 2009 and is encouraged for non-listed large and medium enterprises. This article is current to 2026-11-09 and is a summary of public rules and page method, not legal, internal-control audit or compliance advice; the company's articles, authorization policy, organisation and system configuration control.

This article is for procurement, finance, internal-control, audit, legal 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 authorization and approval-authority matrix page. The usual gap is "amount bands, cumulative basis, delegation/acting authority, emergency purchase, order splitting, segregation of duties, system blocking, annual review", ending with a page that only says "approved according to authority", while ordering/payment/audit still disagree.

How does this page relate to requisition/approval (PR→PO), budget, contract, internal-audit and master-data pages?

The authorization-matrix page answers "who may approve what, how delegation/acting authority works, how authority is revoked"; the requisition/approval (PR→PO) page answers "how demand is raised, what is approved, how the workflow runs"; the budget page answers "limit/encumbrance/execution/overrun"; the contract page answers "clauses/signing/versions"; the internal-audit page answers "plan/sampling/evidence/remediation"; the master-data page answers "roles/permission data/change approval". The authorization matrix is the common precondition and cannot be replaced by a PR→PO workflow page.

Common breaks: only a department-head signature, no amount bands; single-transaction view only, no annual cumulative control; verbal delegation; the acting approver and the original approver both sign; emergency purchase becomes "act first, approve later"; order splitting to avoid approval; one person requisitions, sources, accepts and pays; systems do not block over-limit orders; access is not revoked after a role change; no annual review or audit trail. The page separates "levels—dimensions—thresholds—delegation—segregation—systems—review" so procurement/finance/internal-control/audit share one vocabulary.

Page relationships are editorial; the company's articles, authorization policy and system configuration control.

Which levels and dimensions should the matrix cover?

Levels at least: governance (shareholders/board, per the articles, for major investment, related-party transactions, guarantees); management (GM/VP for annual frameworks, large purchases, exceptions); functions (procurement head, finance head, requester head); execution (buyer/expeditor, ordering within limits). Dimensions at least: single-transaction amount, annual cumulative, framework ceiling; category risk (production material, commodities, MRO, services, engineering, IT, hazardous waste); capital vs expense; contract type (new/renewal/change/supplement); sourcing method (tender/RFQ/sole source); urgency; related-party; cross-border/FX. Suggested fields: authority ID, position/role, currency, amount ceiling, category scope, validity, preconditions, approval route, acting approver, reviewer.

Acceptance checks: levels from governance to execution; dimensions cover amount/category/spend/contract/source/emergency/related-party; thresholds distinguish single/cumulative/framework; currency and tax basis; position/role clarity; validity/preconditions; acting approver; approval route; version/effective date. Common gaps: only department head; only single transaction; no cumulative/framework; no category split; unclear tax basis; no acting authority or validity.

Levels and dimensions are editorial; the company's articles, organisation and authorization policy control.

How should amount/risk thresholds be set, and how is order splitting prevented?

Thresholds are not copied from peers; set them by company size, category risk, transaction history, cash flow and audit findings. At minimum distinguish single transaction, annual cumulative and framework ceiling, and define tax-inclusive/exclusive basis, currency and FX conversion. Anti-splitting: aggregate multiple orders to the same supplier/project/requirement within a short window; accumulate order changes/supplements; monitor annual framework usage; system warnings near the threshold; mandatory escalation above it. Emergency purchase should be limited by scenario, amount and time, with after-the-fact approval/review, not normal practice. Related-party transactions should be identified, disclosed, recused and approved per the articles/regulatory rules.

Acceptance checks: threshold basis; single/cumulative/framework; tax/currency; anti-splitting rules; system warnings; emergency purchase; related-party; exception approval; annual review. Common gaps: arbitrary thresholds; single transaction only; no splitting detection; emergency first/approve later; related-party not identified.

Thresholds and anti-splitting controls are editorial; the company's authorization policy, budget and system capability control.

How should delegation, acting authority and temporary authority be managed?

Authority should be in writing: delegator, delegate, matter/category, amount ceiling, currency, period, preconditions, whether re-delegation is allowed, reviewer. Delegation does not automatically extend further; no re-delegation without permission; acting authority must stay within scope and period, and the original approver must not co-sign the same matter; temporary authority (leave, travel, vacancy) must state start/end, scope, amount and revocation. On role change, departure or reorganisation, revoke system access and written authority promptly and update the matrix version. The authority register must reconcile with system roles and contract/order/payment records.

Acceptance checks: written authority; scope/limit/period; re-delegation rule; acting conflict; temporary authority; revocation; register; system sync. Common gaps: verbal; indefinite; co-signing; no revocation on departure; register and system differ.

Delegation/acting authority is editorial; the company's authorization policy, articles and system permissions control.

How should segregation of duties and system controls be accepted?

Incompatible duties include at least: requisition vs approval; RFQ vs supplier selection; contract drafting vs review; purchasing vs acceptance; payment approval vs payment execution; business handling vs accounting. Controls: job separation, system role separation, approval routing by amount/category, over-limit blocking, order-splitting/duplicate-order/duplicate-payment warnings, dual verification of supplier bank-account changes, audit trail on key fields, periodic access review and time-limited emergency access. Policy text must map to system configuration and actual documents, not just paper. MOF Guideline No. 7 also requires that, except for small miscellaneous items, one organisation must not handle the whole procurement process, and important/technical purchases should be expert-reviewed and collectively decided/approved.

Acceptance checks: incompatible-duty list; job/role separation; approval routing; over-limit blocking; splitting/duplicate checks; bank change; log; access review; emergency access. Common gaps: one person end-to-end; over-broad system roles; bypassable limits; no log; access never reviewed.

Controls are editorial; the company's internal-control policy, system configuration and audit requirements control.

How should the website page be written, and what must not be published?

Suggested sections: (1) authorization principles and levels; (2) matrix elements (amount/category/spend type/contract type/source); (3) delegation/acting/temporary rules; (4) segregation of duties and system controls; (5) contact window/update date. The public page explains "principles, levels, roles, process, boundaries" and does not publish specific approval amounts, approver names/contacts, system screenshots, accounts, supplier quotations/contracts, bank accounts or undisclosed related-party transactions. Listed or regulated companies follow disclosure rules. The English page should use consistent terms (delegation of authority, approval matrix, thresholds, sub-delegation, acting authority, segregation of duties, override, audit trail) and state the cut-off date.

Do not turn the authorization matrix into a full internal policy; do not write "all purchases must be signed by the chairman" if that cannot be executed. The page should let suppliers and customers know "whom to contact, on what principle, how long a reply takes", without exposing internal risk-control details.

The page structure is editorial; public statements must be true and verifiable, and the company's authorization policy and disclosure requirements control.

Go-live acceptance checklist

Ten checks: level coverage; single/cumulative/framework basis; category/spend/contract/source dimensions; threshold basis and anti-splitting; delegation/acting/temporary/revocation; segregation of duties; system routing/blocking/log; related-party/emergency; annual review/version; public boundary. Each needs evidence and a review date. The pass standard is not "the page says approved according to authority", but that procurement/finance/internal-control/audit can judge who may approve, what happens above the limit, whether acting authority is valid and whether the system blocks it.

Before go-live, run a tabletop exercise with a real (redacted) purchase: requisition → budget → RFQ → supplier selection → contract → order → acceptance → payment, simulating "over-limit", "splitting", "acting authority", "emergency purchase" and "supplier bank change" to see whether the matrix and system work.

The acceptance list is editorial; the company's authorization policy, system configuration and audit requirements control.

Who should read it, who should not, and what decisions does it support?

For procurement, finance, internal-control, audit, legal and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies handling "approval depends on people, no amount bands, verbal delegation, emergency purchase as normal, order splitting, systems do not block, access not revoked on departure". Not for teams without a procurement approval process, or that want one page to replace legal advice/internal-control audit.

Read it if: building an authorization-matrix page; only "approved according to authority"; unclear amount bands; annual cumulative/framework uncontrolled; verbal delegation/acting; emergency first/approve later; splitting; one person end-to-end; no system block; access never reviewed. Not suitable if: treating "authority" as "signature"; "acting" as "delegation"; "policy on the wall" as "system control"; "page" as "audit conclusion". Supports: levels/dimensions, thresholds/splitting, delegation/acting, segregation, system controls, review and public-boundary self-checks.

FAQ

What should a procurement authorization matrix contain at minimum?

At least authority levels (governance/management/function/execution), dimensions (amount, category risk, spend type, contract type, sourcing method, emergency, related-party), amount basis (single/cumulative/framework, tax, currency), approval route, delegation/acting rules, validity, reviewer and version. The matrix must map to system roles and actual documents, not just a signature sheet.

Are lower amount thresholds always better?

No. Too low pushes many small purchases to senior management, reduces efficiency and encourages splitting; too high loses control. Set thresholds by company size, category risk, transaction history, cash flow and audit findings, distinguish single/cumulative/framework and review periodically. The key is "escalation above the limit, detection of splitting, review of exceptions", not a fixed number.

Can delegation and acting authority be verbal?

Not advisable. Delegation/acting authority should be written (or traceable in the system) with delegator, delegate, matter/category, amount ceiling, period, whether re-delegation is allowed and reviewer; acting must not exceed scope; the original approver and acting approver must not both sign the same matter; revoke on role change, departure or expiry. Verbal authority is hard to prove in an audit.

Can emergency purchase be "act first, approve later"?

Only as an exception within limited scenario, amount and time, with after-the-fact approval, review and post-mortem. It must not become normal practice or bypass tender/RFQ/budget. The page should state the trigger, approver, catch-up deadline and evidence; the system should flag it and include it in audit sampling.

How can order splitting be prevented?

Aggregate orders to the same supplier, same project/requirement or same budget line within a defined time window; accumulate order changes/supplements; monitor annual framework usage; warn near the threshold and mandate escalation above it; audit short-window multiple orders, consecutive numbers and deliberate fragmentation. Manual judgement alone misses too much; put rules into the system and ledger.

How does the authorization matrix relate to the PR→PO page?

The PR→PO page covers "how demand is raised, what the requisition contains, how the approval workflow runs and how it is recorded"; the authorization matrix covers "who may approve what, whom to escalate to, whether delegation/acting is valid and which positions cannot be combined". They complement each other: without the matrix, the workflow page can only say "according to authority"; without the workflow page, the matrix cannot reach documents and systems.

Should the website publish specific approval amounts and approvers?

Usually not specific thresholds, approver names/contacts, system screenshots, accounts, supplier quotations/contracts, bank accounts or undisclosed related-party transactions. It can publish authorization principles, levels, roles, process, contact window and update date. Listed or regulated companies follow disclosure rules. The goal is to let suppliers know "whom to contact and on what principle", not to expose internal risk-control details.

One-sentence takeaway

The procurement authorization and approval-authority matrix page on a Changzhou manufacturer's website is not about "approved according to authority"; it is about turning levels, single/cumulative/framework basis, category/spend/contract/source dimensions, thresholds and anti-splitting, delegation/acting/temporary authority, segregation of duties, system blocking/audit trail, exceptions and annual review, and public boundaries into a checkable list, so procurement/finance/internal-control/audit can judge who may approve, what happens above the limit, whether acting authority is valid and whether the system blocks it.

Research method and limitations

This article is a summary of public rules and page method, not legal, internal-control audit or compliance advice. It uses no unpublished company approval amounts, approver information, system screenshots, supplier quotations/contracts or undisclosed related-party transactions; the tables and acceptance items are editorial and not internal-control/audit conclusions. MOF Internal Control Application Guideline No. 7 (Procurement), No. 6 (Fund Activities) and No. 18 (Information Systems) are public sources; the Basic Standard for Enterprise Internal Control applies to listed companies from 1 July 2009 and is encouraged for non-listed large and medium enterprises. This article does not decide whether any specific authorization limit is reasonable, and does not promise "no fraud/no override"; companies should set them item by item based on articles, organisation, system capability and audit requirements.

Sources and basis

Current to 2026-11-09; the official pages below control.

1. MOF Internal Control Application Guideline No. 7 — Procurement (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Article 4 defines duties and approval authority for requisition, approval, purchasing, acceptance, payment and post-purchase review; Article 5 requires expert review and collective decision/approval for important purchases and prohibits one organisation from handling the whole process except for small miscellaneous items; Article 6 defines requisition rights and approval procedure; Article 10 requires signing contracts within authority; Article 13 defines the payment reviewer's responsibility and power.
2. MOF Internal Control Application Guideline No. 6 — Fund Activities (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Article 4 requires authorization, approval and verification systems, defined duties and segregation; Article 21 requires strict payment conditions, procedures and approval authority, authorization before payment, and prohibits one person from handling the whole cash process.
3. 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; used here as the public basis for system permission/workflow/log controls.