Supplier Master Data and Bank-Account Change Pages on Changzhou Manufacturer Websites: How Should They Be Accepted?

Direct answer: A supplier master-data and bank-account change page is not "email us the new account". The website page should state: which fields can change (name, unified social credit code, address/phone, legal representative, bank, account number, invoicing details, contact), who may apply and with what authorisation, dual review and separation of duties, callback verification using contract or historical contacts (never the new number in the request), the effective date and treatment of in-flight orders/invoices/payments, retirement of the old account, change records and audit trail, and incident/fraud handling. On the law: where a person acts without authority, beyond authority or after authority has ended, the act does not bind the principal unless ratified; where the counterparty has reason to believe the person has authority, the agency act is valid (Civil Code Articles 171 and 172). Parties may agree to change a contract, but an unclear change is presumed not made (Articles 543 and 544); an assignment of a claim does not bind the debtor unless notified (Article 546). Company registration changes must be registered, and an unregistered or unamended item cannot be asserted against a bona fide third party (Company Law Article 34); registration items are published through the National Enterprise Credit Information Publicity System (Article 32). Invoices must be issued truthfully, and non-compliant invoices may be refused as reimbursement vouchers (Invoice Administration Measures Articles 20 and 21). No unit or individual may illegally buy, sell, lend or rent bank accounts, or open accounts by impersonation or fictitious agency (Anti-Telecom and Online Fraud Law Article 31). Information is current to 2026-11-07. This is a review of public rules and page practice, not legal, financial, tax or anti-fraud advice; the contract, authorisation, bank rules and company policy control.

This guide is for procurement, finance, tax, legal, IT and website teams at equipment, electronics/electrical, automotive, medical device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby areas. This page most often misses who may change what, on what authority, how it is verified, when it takes effect and what happens to in-flight payments, ending up as "please contact your buyer".

How does this page relate to payment terms, three-way match and supplier portal pages?

The master-data/account-change page answers "how a supplier's name, tax number, bank, account and contacts change, who may change them and when the change takes effect"; the payment terms and settlement page answers prepayment, credit terms, acceptance bills, invoices and overdue handling; the procurement three-way match/reconciliation page answers how order, receipt and invoice align; the supplier portal/SRM page answers registration, orders/ASN, e-signature and data security. The change page is the entry point for master data and funds; a payment page or portal login cannot replace it.

Common breakpoints: only "contact your buyer"; no authorisation or seal requirements; procurement and finance each change their own copy; calling the new number in the email; paying to the new account the same day; the old account stays active; invoice name/tax number does not match registration; the portal lets suppliers self-edit bank details without review; change records cannot be found. Separate "scope—applicant—documents—review—verification—effective date—incident"; then procurement, finance, legal and IT share one playbook.

This page map is editorial; the contract, authorisation, bank rules and company policy control.

How should the change scope be defined?

First list which fields count as master data: supplier name, unified social credit code, registered/operating address, phone, legal representative, bank, account number, invoicing details (name/tax number/address and phone/bank and account), contact/email/mobile. Risk differs by field: a contact change may use a light process, while name/tax number/bank/account changes need full authorisation and review. The page should state which fields need written documents, which can be self-edited in the portal and which require the legal representative's signature or seal—do not let suppliers decide.

Acceptance checks: field list; risk tiers; required documents; channel; turnaround; effective rule. Common gaps: incomplete fields; one process for bank and contact; portal can edit everything; no turnaround; finance not notified after the change.

Field tiers are editorial; the company master-data policy and contract control.

How should the applicant, authorisation and seals be accepted?

The change should be requested by the supplier itself or a lawful authorised representative. The page should list: change request letter (company seal or contract seal), legal representative ID proof, power of attorney (matters, authority, term), business licence, bank account certificate/basic deposit account information, registration change certificate (for name/legal representative changes) and the handler's ID. The power of attorney should state whether the person may change the payment account—"handle business" is not enough. Seals should be compared with the contract/historical documents; electronic signatures are judged by reliability under the Electronic Signature Law, not by an image.

Acceptance checks: applicant; authority scope; term; seal; completeness; original/copy; e-signature; filing. Common gaps: scans only; "full authority"; no term; blurred seal; no handler ID; documents not filed.

This document list is editorial; legal/finance policy controls.

How should dual review and separation of duties be accepted?

A bank-account change needs at least "business request—business review—finance review—approval—master-data maintenance—payment execution" separated; one person should not run the whole chain. The page may describe roles and turnaround, but should not publish internal approver names or phone numbers. Key controls: the person changing the account is not the person paying; master-data maintenance is separate from approval; large or first payments to a new account require extra sign-off; review is heightened for a period after the change. The policy should state who is accountable for what, not "everyone takes a look".

Acceptance checks: roles; separation; approval levels; turnaround; delegation; records; spot checks. Common gaps: one person end-to-end; approval only by amount; no delegation rule; no turnaround; no change log; no spot check.

Separation of duties is editorial; internal control/authorisation policy controls.

How should callback verification be done?

Callback verification is the key anti-fraud step: call the phone number on the contract, historical orders or supplier onboarding file, or the public switchboard on the supplier's website—not the new number in the change email/SMS, and do not click links or QR codes in the email. Confirm at least: fields changed, bank, account number, effective date, handler name/employee ID and authorisation document number. Record time, number, person reached and conclusion; if unreachable, use a second channel, and if still unreachable, hold. The verifier must not be the requester.

Acceptance checks: number source; content; record; second confirmation; hold rule; verifier. Common gaps: calling the new number; email confirmation only; no record; requester verifies; releasing when unreachable; voice chat instead of a call.

Callback verification is editorial; anti-fraud/treasury policy controls.

How should the effective date and in-flight orders, invoices and payments be handled?

The page should state from which date/time the change takes effect and distinguish: orders placed, goods received but not invoiced, invoiced but not paid, payment in transit, and batches under reconciliation. A common approach is "effective from the next payment cycle after approval", with the old account before and the new account after; the old account is frozen/marked inactive; in-flight payments are checked for stop/redirect. Where a contract change is unclear, it is presumed not made (Civil Code Article 544), so the effective date, applicable batches and old-account treatment must be written, not verbal.

Acceptance checks: effective date; applicable batches; old account; in-flight orders; in-flight invoices; in-flight payments; notice; records. Common gaps: same-day effect; no batch split; old account still collects; in-flight payments unchecked; only procurement notified; no effective notice.

Effective rules are editorial; the contract/payment policy controls.

How should invoice and tax details be matched?

Invoice details must match supplier registration and the actual transaction: name, unified social credit code, address and phone, bank and account, goods or service description, amount and tax rate. The Invoice Administration Measures require truthful issuance in the prescribed time, sequence and fields, and prohibit false invoicing; non-compliant invoices may not be used as reimbursement vouchers and any unit or individual may refuse them (Articles 20 and 21). After a name/tax-number change, invoices under the old title may not be deductible or bookable, so agree with the supplier on red-letter reversal and reissue; electronic invoices need the same title, tax number and item check. The page should state the first-invoice checkpoints after a change.

Acceptance checks: title; tax number; address/phone; bank/account; item description; red-letter; e-invoice; checker. Common gaps: system updated but not invoices; old-title invoices still accepted; item description not matching the contract; no red-letter record; e-invoice unchecked; two versions of details.

Invoice requirements follow Articles 19–23 of the Invoice Administration Measures; tax rules and company finance policy control.

How should systems, permissions and logs be accepted?

The change must land in the system: field-level permissions, approval flow, before/after values, operator, timestamp, attachments, effective status and retained old values. If the supplier portal allows self-service, limit editable fields (such as contacts); bank and invoicing details must go through internal review. Interface sync should have validation and reconciliation so ERP, SRM and online banking do not diverge. Logs should be searchable and exportable, retained per company/legal requirements.

Acceptance checks: field permissions; approval flow; logs; attachments; old values; portal limits; interfaces; reconciliation. Common gaps: admins can edit directly; logs have results but no old values; portal can edit the account; no interface validation; three systems diverge; logs cannot be exported.

System controls are editorial; IT/internal control policy controls.

How should incidents and fraud be handled?

The page needs a "what to do if suspicious" section: suspicious email/SMS/WeChat, impersonation of the boss or buyer, payment pressure, requests to change an account, impersonation of the legal representative, an account already misused, or a payment already made. Suggested order: hold payment → preserve evidence (email headers, chat logs, call recordings, account, time) → contact the supplier via a known number → notify the bank/stop payment → report to police → escalate internally → review. The Anti-Telecom and Online Fraud Law prohibits illegally buying, selling, lending or renting bank accounts and opening accounts by impersonation or fictitious agency (Article 31); leads may be reported to public security.

Acceptance checks: suspicious scenarios; hold rule; evidence; contact channel; stop payment; police report; escalation; review. Common gaps: no "stop payment first"; screenshots only; verifying via the fraudster's number; bank not notified; no police report; no review.

Handling suggestions are editorial; company emergency plans and police requirements control.

How should the legal boundaries be understood?

Keep four points separate: (1) Agency—acts without authority, beyond authority or after authority ends do not bind the principal unless ratified; where the counterparty has reason to believe there is authority, the act is valid (Civil Code Articles 171 and 172). (2) Contract change—parties may agree to change; an unclear change is presumed not made (Articles 543 and 544). (3) Assignment of claims—an assignment does not bind the debtor unless notified (Article 546), so "the payee changed" may be an account change or an assignment. (4) Registration and invoices—company registration changes must be registered, and an unregistered item cannot be asserted against a bona fide third party (Company Law Article 34); invoices must be truthful and non-compliant ones may be refused (Invoice Measures Articles 20 and 21). The page may flag these rules but must not decide a specific case.

Acceptance checks: whether the page distinguishes agency/change/assignment; requires writing; states notice and service; advises counsel for specific cases; avoids treating "apparent authority" as a universal defence. Common gaps: "our records prevail"; blaming the supplier for any fraudulent payment; treating "reason to believe" as always satisfied; no notice method.

Statutory summaries follow the Civil Code, Company Law, Invoice Administration Measures and Anti-Telecom and Online Fraud Law; the original text and court/enforcement practice control.

How should the supplier master-data/account-change page be written?

Suggested content: (1) scope (which suppliers/fields); (2) change list and risk tiers; (3) required documents and seals; (4) process and turnaround; (5) dual review and callback verification; (6) effective date and in-flight orders/invoices/payments; (7) old-account retirement; (8) invoice/tax details; (9) incidents and fraud warnings; (10) contact, version and update date. The public page explains rules and entry points; it should not publish internal approvers, account whitelists or risk thresholds; after login, suppliers can see their own change status. State "the contract, authorisation and company policy control"; do not write "email us to change / same-day effect".

Use consistent English terms (supplier master data, bank-account change, authorised signatory, dual review, callback verification, effective date, in-flight payment, fraud prevention) and state the review date. Link to payment terms, three-way match and supplier portal pages, but do not turn the change page into a finance payment page.

This structure is editorial; external statements must be truthful and verifiable, per the contract and company policy.

What must not be written?

High-risk claims: "email us to change the account" (no authority/review); "effective same day" (in-flight payments/invoices unhandled); "call the new number to confirm" (the fraud entry point); "a seal makes it valid" (seals can be forged/exceeded); "paying the new account discharges the obligation" (discharge depends on contract/agency/notice); "the supplier updates it and everything syncs" (system/invoice/bank are three sets); "an account change does not affect invoices" (title/tax number may change); "publish approvers and whitelists" (internal risk information). These are inaccurate or misstate authority, effect or liability.

Safer wording: "This page applies to [supplier type/fields]; changes require [documents] and [review/approval]; we verify by callback to [historical contact]; the change takes effect from [date/batch], and the old account is [retirement method]; in-flight orders/invoices/payments follow [rule]; for suspicious cases contact [channel]; we [hold/stop/police]. The contract, authorisation and company policy control." External promotion must comply with advertising and fair-competition rules; supplier information needs authorisation or redaction.

Go-live acceptance checklist

Ten checks: scope and tiers, applicant and authority, documents and seals, separation of duties, callback verification, effective date and in-flight handling, invoice/tax, system permissions and logs, incidents and fraud, page wording and version. Each needs an owner, evidence and review date. The pass condition is not "the page lists a change mailbox", but that procurement, finance, legal, IT and suppliers can find the entry, documents, verification, effective date and incident rules.

Before go-live, run one real (anonymised) change through: request → documents → review → callback → approval → master data → effective → in-flight → invoice → filing. Any step that fails is a gap in the page or the process.

This checklist is editorial; the contract, authorisation and company policy control.

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

It suits procurement, finance, tax, legal, IT and website teams at equipment, electronics/electrical, automotive, medical device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby areas; also companies building a supplier master-data change page for the first time, or that have faced "supplier account change / payment pressure" fraud. It does not suit teams that only handle sales receipts, do not maintain supplier master data, or want one page to replace legal/financial advice.

Read it if you are building a master-data/account-change page; authority and documents are unclear; procurement and finance each edit their own copy; verification uses the new email number; in-flight payments are unhandled; invoice titles do not match; the portal lets suppliers edit bank details. Skip it if you treat "email us" as a process, the new number as a verification channel, any fraudulent payment as the supplier's fault, or want to publish approvers/whitelists. It supports self-review of scope tiers, authority documents, separation of duties, callback verification, effective/in-flight handling, invoices, system logs, incidents and page wording.

FAQ

A supplier emailed a new bank account. Can we just change it?

Not advisable. At minimum verify the applicant and authority (power of attorney, legal representative/seal), call back using the contract or historical contact, have a second person review and keep records. Changing an account on an email alone is a classic fraud entry point; follow company policy.

Which number should the callback use?

Use the phone on the contract, historical orders, supplier onboarding file or the public switchboard on the supplier's website—not the new number in the change email/SMS, and do not click links. Record time, number, person and conclusion; if unreachable, try another channel or hold.

When does the change take effect, and what about in-flight payments?

The page should state the effective date/batch and old-account handling. A common approach is the next payment cycle after approval, old account before and new after; check orders placed, invoices issued but unpaid, and payments in transit, and stop/redirect if needed. An unclear contract change is presumed not made (Civil Code Article 544).

The supplier's name/tax number changed. How are invoices handled?

Verify the registration change certificate, update invoicing details, and reverse/reissue old-title invoices per tax rules; non-compliant invoices may be refused (Invoice Measures Articles 20 and 21). Check name, tax number, address/phone and bank/account together—not just the system.

What does apparent authority have to do with payment?

Civil Code Article 172 provides that where a person acts without authority, beyond authority or after authority ends, and the counterparty has reason to believe there is authority, the agency act is valid. Whether there is "reason to believe" depends on the facts (course of dealing, seals, appearance of authority) and cannot be generalised; Article 171 provides that an unratified act does not bind the principal. Consult counsel for a specific case.

Should the website publish the change process and forms?

It may publish the rules, document list, entry point, turnaround and fraud warnings to help suppliers prepare; do not publish internal approvers, account whitelists or risk thresholds. After login, suppliers can see their own status; the public page states that the contract and company policy control.

One-sentence takeaway

A Changzhou manufacturer's supplier master-data/account-change page is not about "leave an email". It should turn scope tiers, authority documents, dual review, callback verification, effective/in-flight handling, invoices, system logs, incident response and page wording into a reviewable checklist—so procurement, finance, legal, IT and suppliers can change correctly, verify solidly and pay safely.

Method and limitations

This is a review of public rules and page practice, not legal, financial, tax or anti-fraud advice. No undisclosed customer, account, price or supplier data were used; processes, documents, tables and acceptance items are editorial, not legal/financial conclusions. Agency and contract change follow Civil Code Articles 171/172/543/544/546; registration and publicity follow Company Law Articles 32/34/40; invoices follow Articles 19–23 of the Invoice Administration Measures; account lending and fictitious agency follow Article 31 of the Anti-Telecom and Online Fraud Law; the original law, contract, authorisation, bank rules and company policy control.

Sources and scope

Information is current to 2026-11-07. The following are official pages; their text controls.

1. Civil Code of the People's Republic of China: Supreme People's Court. No/beyond authority and apparent authority (Articles 171, 172), contract change (Articles 543, 544), assignment notice (Article 546).
2. Company Law of the People's Republic of China (2023 revision): NPC website. Registration publicity (Article 32), change registration and effect against third parties (Article 34), publicity duties (Article 40).
3. Invoice Administration Measures of the People's Republic of China (2023 revision): State Taxation Administration policy database. Obtaining invoices (Article 19), refusing non-compliant invoices (Article 20), truthful issuance/prohibition of false invoicing (Article 21), invoice data (Article 23).
4. Anti-Telecom and Online Fraud Law of the People's Republic of China: NPC website. Prohibition on buying/selling/lending/renting bank accounts and on opening accounts by impersonation or fictitious agency (Article 31).