Procurement Three-Way Match / Reconciliation Pages on Changzhou Manufacturer Websites: How Should They Be Accepted?

Direct answer: A procurement "three-way match" is not uploading three documents; it aligns the purchase order (PO), goods receipt (GR) and invoice by the same supplier, item/model, quantity, unit price/tax rate and batch/date. Differences must be suspended, adjusted or red-lettered—not paid straight through. The procurement reconciliation page on a manufacturer's website should let suppliers see "order—receipt—statement—invoice status—deviation reason—red-letter/reissue—payment plan", with permissions and data boundaries stated. On the invoice side: an invoice is a payment/receipt voucher; electronic and paper invoices have equal legal effect; when obtaining an invoice, the buyer may not request a change of product name or amount; a non-compliant invoice may not be used as a financial reimbursement voucher and may be refused; false invoicing, substituting other documents for invoices, and tampering with/leaking invoice data are prohibited. Information is current to 2026-11-07. This is a review of public rules and page practice, not tax, accounting, legal or payment advice; the current invoice rules, e-invoice announcement, tax system and contract control.

This guide is for procurement, finance, quality, 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 matching fields, tolerances, deviation reasons, red-letter/reissue and permissions, ending up as "suppliers download their own statement".

How does this page relate to the supplier portal, customer portal and payment terms pages?

The procurement reconciliation/three-way match page answers "how the supplier's order, receipt and invoice align, how differences are handled, and when payment happens"; the supplier portal / SRM page answers registration, RFQ, orders/ASN, e-signature and data security; the customer portal (orders/shipping/reconciliation) page answers our sales-side reconciliation with customers; the payment terms/settlement page answers prepayment, credit terms, acceptance bills, invoices and overdue handling. Different objects: SRM is the entry, three-way match is the check, the customer portal is the sales side, and payment terms are the settlement rules.

Common breakpoints: "upload invoice" treated as "reconciliation complete"; supplier names differ across PO/GR/invoice; quantity/price/tax differences have no reason; red-letter/reissue has no record; the statement has no version/confirmation; one supplier can see another's prices; payment plan is disconnected from reconciliation; permissions too broad/no logs. Separate "order—receipt—invoice—match—deviation—red-letter—payment"; then procurement, finance, quality and suppliers share one playbook.

This page map is editorial; the contract, order, invoice and finance policy control.

What are the three documents and which fields must match?

The three documents are usually the purchase order (PO), goods receipt (GR) and invoice. At minimum, match supplier name/tax ID, PO number/line, item code/model/specification, quantity, unit price/tax-inclusive price, tax rate/tax amount, amount/total, delivery/receipt date, batch/serial number and currency/exchange rate (if foreign currency). The invoice should also show invoice number/code, issue date, buyer/seller information, item name, specification/model, unit, quantity, unit price, amount, tax rate/levy rate, tax amount, total and remarks. "Same item" should align by item code/model, not just product name.

Acceptance checks: unique numbers; supplier/tax ID consistent; PO line traceable to receipt/invoice; item code/model consistent; quantity/price/tax calculable; batch/date traceable; currency/exchange-rate basis. Common gaps: name only, no code; missing PO line; receipt without batch; invoice item name differs from order; rounding difference unexplained.

The field list is editorial; the order, receipt, invoice and finance policy control.

How should the purchase order (PO) be accepted?

A PO should independently answer "buy from whom, what, how much, at what price, when/where delivered, how settled". The page/system PO should at least include PO number/version, supplier name/tax ID, item code/model/specification, quantity/unit, unit price/tax rate/currency, delivery date/place, payment terms, receiver/contact and change record. PO changes should keep the version and effective time, so a supplier cannot ship against an old PO while finance pays against a new one.

Acceptance checks: PO number/version; supplier; item; quantity/unit; price/tax; delivery/place; payment terms; change record; consistency with the contract. Common gaps: no version; verbal changes; price/tax differs from contract; unit mismatch; delivery change not notified; old PO still downloadable.

PO fields are editorial; the contract/order and finance policy control.

How should the goods receipt (GR) be accepted?

The GR should prove "what was actually received, how much, when, which batch, and its quality status". It should at least include GR number, PO number/line, supplier, item code/model, ordered/received quantity, unit, batch/serial number, receipt date/warehouse, quality status (accepted/pending/rejected/concession), short/over shipment, damage/return and receiver/document. Receipt quantity is key to matching and payment; "arrived" is not enough.

Acceptance checks: GR number; PO/line; item; ordered/received; batch; date/warehouse; quality status; deviation; signature/record. Common gaps: no PO line; receipt not linked to order; missing batch; pending inspection counted as payable; short/over shipment unrecorded; no receiver signature.

Receipt fields are editorial; warehouse/quality/finance policy control.

How should invoices/e-invoices be accepted?

An invoice is a payment/receipt voucher for the sale of goods, provision of services and other business activities; invoices include paper and electronic invoices, which have equal legal effect. When paying for goods/services, the buyer should obtain an invoice from the seller; when obtaining it, the buyer may not request a change of product name or amount; a non-compliant invoice may not be used as a financial reimbursement voucher and may be refused. A fully digitalized e-invoice is a type of electronic invoice, promoted nationwide from 1 December 2024; it is a single copy with a 20-digit number and includes buyer/seller, item, specification/model, unit, quantity, unit price, amount, tax rate/levy rate, tax amount and total; it can be verified free of charge via the e-invoice service platform or the national VAT invoice verification platform.

Acceptance checks: invoice type; number/code; issue date; buyer/seller name/tax ID; item/spec/unit/quantity/price/amount/tax/total; remarks; verification result; consistency with PO/GR. Common gaps: wrong buyer name/tax ID; item name differs from order; quantity/price/tax mismatch; duplicate number; not verified; paper/electronic mixed without filing.

Invoice requirements follow the invoice rules and the 2024 e-invoice announcement; the tax system/authority control.

How should matching rules/tolerances be accepted?

The matching rule should state "what is matched first, what difference is allowed, and what happens beyond tolerance". A suggested order: supplier/tax ID → PO number/line → item code/model → quantity (receipt vs invoice vs order) → unit price/tax amount → date/batch. Tolerance (quantity/price/amount/tax) has no uniform statutory percentage; it is an internal control/contract matter. The page should state the tolerance, base, approver and what happens beyond tolerance (suspend/adjust/red-letter), not hide differences behind an "auto-approve" button.

Acceptance checks: matching order; tolerance; base; over-tolerance handling; approval; record; exceptions. Common gaps: total amount only; tolerance too wide; auto-posting beyond tolerance; no approval record; tax difference ignored; discounts/allowances not reflected.

Tolerance/rules are editorial, not a uniform statutory percentage; internal control/contract control.

How should deviations be handled?

Classify deviations: quantity (short/over), price (unit price/tax/freight/discount), item (model/substitute), time (early/late/cross-period) and documents (missing PO/receipt/wrong invoice). Each needs a reason code, responsible party, disposition (replenish/return/price adjustment/red-letter/reissue/hold), deadline, approval and evidence. "Deviation handled" alone is not enough; the supplier should see why it is held, who does what next, and when payment happens.

Acceptance checks: deviation type; reason; responsibility; disposition; deadline; approval; evidence; status. Common gaps: no reason code; long-held deviations; unclear responsibility; no red-letter/reissue record; supplier cannot see status; payment disconnected.

Deviation handling is editorial; the contract, finance and tax process control.

How should red-letter, reissue and voiding be accepted?

Under the 2024 e-invoice announcement, after a blue e-invoice is issued, a red-letter e-invoice should be issued for sales returns (full/partial), invoicing errors, suspension of taxable services (full/partial), sales allowances, etc. If the blue invoice has not been use-confirmed or booked, the issuer initiates the red-letter process and directly issues the red-letter invoice; if it has been use-confirmed or booked, either the issuer or the recipient may initiate, and after the other party confirms the Red-Letter Invoice Information Confirmation Form, the issuer issues the red-letter invoice; if the form is not confirmed within 72 hours, it is automatically voided; if the recipient has already deducted input VAT, it should temporarily transfer out the tax amount per the form and, after receiving the red-letter invoice, use it with the form as accounting evidence. The page should state who initiates, who confirms, 72 hours, input VAT transfer-out, and reissue/void records.

Acceptance checks: red-letter reason; initiator; confirmer; confirmation form; 72 hours; input VAT transfer-out; red-letter invoice; reissue/void; filing. Common gaps: no confirmation; over 72 hours; deducted input not transferred out; no link to the original; no void record; invoice status inconsistent with reconciliation.

Red-letter process follows the 2024 e-invoice announcement; the tax system controls.

How should reconciliation, confirmation and payment be accepted?

A statement should have a period, supplier, PO/GR/invoice details, opening/current/closing balances, deviations, confirmation status, version and both parties' confirmation records; the payment plan should be tied to "reconciliation confirmed + invoice compliant + receipt accepted", not just the invoice date. Under the Civil Code, the buyer should pay the price according to the agreed amount, method and time; if unclear, Articles 510/511 apply. The page should state who reconciles, who confirms, how often, payment terms, and how unsettled deviations are handled—not "invoice received, payment made".

Acceptance checks: reconciliation period; details; opening/current/closing; deviations; confirmation; version; payment terms; payment plan; records. Common gaps: no version; total only; supplier not confirmed; payment despite unsettled deviations; payment disconnected; cross-period/FX unclear.

Reconciliation/payment is editorial; the contract, finance policy and Civil Code control.

How should permissions and data boundaries be accepted?

Supplier portals/reconciliation pages are prone to data overreach: supplier A sees supplier B's prices/orders; a buyer sees all suppliers; departed accounts remain active; exports have no logs. The page should state: account bound to the supplier entity; authorisation by supplier/project/order; field-level redaction (other suppliers' prices, costs, customer data); download/export watermark/log; MFA/password policy; timely deactivation on departure/change; audit log retention. Reconciliation data is commercially sensitive and should not be published on the public page.

Acceptance checks: account entity; permission model; field redaction; export/log; MFA; deactivation; audit; retention. Common gaps: shared accounts; over-broad permissions; export without logs; departed accounts active; public reconciliation details; no audit.

Permissions/data boundaries are editorial; enterprise security and the contract control.

How should the procurement reconciliation/three-way match page be written?

Suggested content: (1) applicable suppliers/scope; (2) three-document fields/matching rules/tolerances; (3) reconciliation period/version/confirmation; (4) deviation types/reasons/handling/status; (5) invoice/e-invoice/verification; (6) red-letter/reissue/void; (7) payment terms/plan; (8) permissions/data boundaries/audit; (9) contact/version/update date. The public page should show only the process and a login entry, not orders/prices/invoice details; after login, suppliers see their own data by permission. State "the contract/order/finance policy control"; do not write "upload invoice = reconciliation complete / automatic payment".

Use consistent English terms (three-way match, purchase order (PO), goods receipt (GR), e-invoice, red-letter invoice, reconciliation, tolerance, deviation, audit log) and state the review date. Link to the supplier portal/SRM, customer portal and payment terms pages, but do not present sales-side reconciliation as procurement-side.

This structure is editorial; external statements must be truthful and verifiable, per the contract/finance/tax rules.

What must not be written?

High-risk claims: "upload invoice = reconciliation complete" (three-way match/confirmation still needed); "invoice received = payment" (receipt/acceptance/deviation also matter); "three-way match has a statutory tolerance" (tolerance is internal control/contract, not a uniform statutory percentage); "e-invoices can be printed/screenshotted for booking" (follow tax/accounting filing rules and verify); "red-letter invoices can be issued freely" (follow the process/confirmation; auto-void after 72 hours); "invoice information can change product name/amount" (the buyer may not request changes when obtaining the invoice); "use a receipt/statement instead of an invoice" (other documents may not replace invoices); "publish reconciliation details on the website" (commercially sensitive/overreach). These are inaccurate or misstate the process, tax or permission.

Safer wording: "This page applies to [supplier/category]; the three documents are PO/GR/invoice; matching fields [list], tolerance [company policy]; reconciliation period [period], deviations [type/handling]; invoice [type/verification/red-letter]; payment [terms/plan]; permissions [account/redaction/log]. The contract, order, finance and tax rules control." External promotion must comply with advertising and fair-competition rules; supplier data needs authorisation or redaction.

Go-live acceptance checklist

Ten checks: three-document fields, PO, GR, invoice/e-invoice, matching/tolerance, deviations, red-letter/reissue, reconciliation/payment, permissions/audit, page wording/date. Each needs an owner, evidence and review date. The pass condition is not "the page uploads invoices", but that procurement/finance/suppliers can find the order, receipt, invoice, deviation, red-letter and payment status.

Before go-live, run one real supplier/order through: PO → GR → invoice → match → deviation → red-letter/reissue → reconciliation → payment → permissions/audit → page wording. Any step that fails is a gap in the page or process.

This checklist is editorial; the contract, finance and tax rules control.

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

It suits procurement, finance, quality, 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 reconciliation portal for the first time, or facing reconciliation disputes/invoice rejections/frequent red-letter invoices/payment disconnected from receipts. It does not suit teams that only run a sales-side customer portal, do not touch procurement reconciliation, or want one page to replace tax/accounting/legal advice.

Read it if you are building a supplier reconciliation/three-way match page; PO/GR/invoice fields do not align; deviations have no reason; red-letter/reissue is unclear; payment is disconnected from reconciliation; permissions are too broad. Skip it if you treat uploading invoices as reconciliation, invoices as payment triggers, three-way match as tax filing, or want the page to publish supplier details. It supports self-review of three-document fields, PO, GR, invoice/e-invoice, matching/tolerance, deviations, red-letter, reconciliation/payment, permissions and page wording.

FAQ

What are the three documents in a three-way match?

Usually the purchase order (PO), goods receipt (GR) and invoice. Match supplier/tax ID, PO number/line, item code/model, quantity, unit price/tax rate, amount, batch/date; differences are suspended, adjusted or red-lettered, not paid straight through.

Do e-invoices have the same effect as paper invoices?

Yes. The invoice rules state that electronic and paper invoices have equal legal effect. A fully digitalized e-invoice is a type of electronic invoice, promoted nationwide from 1 December 2024; it is a single copy with a 20-digit number and can be verified free of charge via the e-invoice service platform or the national VAT invoice verification platform.

What if the invoice information does not match?

First classify the difference (buyer/tax ID, item/model, quantity/price, tax amount), and check against the contract/order/receipt. A non-compliant invoice may not be used as a financial reimbursement voucher and may be refused. Reissue or red-letter per the process; the buyer may not request a change of product name or amount when obtaining the invoice.

Who initiates a red-letter invoice, and what is the 72-hour rule?

If the blue e-invoice has not been use-confirmed/booked, the issuer initiates and directly issues the red-letter invoice; if it has been confirmed/booked, either party may initiate, and after the other party confirms the Red-Letter Invoice Information Confirmation Form, the issuer issues it; if the form is not confirmed within 72 hours, it is automatically voided. If input VAT has been deducted, transfer it out per the form first.

Is there a statutory tolerance for three-way matching?

No uniform statutory percentage; tolerance is an internal control/contract matter. The page should state the tolerance ratio/base, who approves, and how over-tolerance is handled (suspend/adjust/red-letter), not hide differences behind an "auto-approve" button.

Will publishing reconciliation data on the website leak information?

Reconciliation/prices/invoices are commercially sensitive and should not be published publicly; put them behind a supplier portal login, authorise by supplier/project/order, redact fields, watermark/log exports, use MFA, deactivate departed accounts and keep audit logs.

One-sentence takeaway

A Changzhou manufacturer's procurement reconciliation/three-way match page is not about "uploading invoices". It should turn PO, GR and invoice fields/matching/tolerance, deviations, red-letter/reissue, reconciliation/payment and permissions/audit into a reviewable checklist—so procurement, finance and suppliers can find the order, receipt, invoice, deviation and payment status.

Method and limitations

This is a review of public rules and page practice, not tax, accounting, legal or payment advice. No undisclosed customer, price, invoice or supplier data were used; processes, fields, tolerances, tables and acceptance items are editorial, not tax/legal conclusions. Invoice/e-invoice/red-letter operations follow the invoice rules, the 2024 e-invoice announcement, the tax system and the competent tax authority; three-way matching/tolerance is internal control/contract, not a uniform statutory standard.

Sources and scope

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

1. Measures for the Administration of Invoices (2023 revision): State Taxation Administration policy database. Invoice definition/electronic effect, obtaining/issuing, false invoicing, substitution, five-year stub retention.
2. State Taxation Administration Announcement No. 11 of 2024 on Promoting Fully Digitalized E-Invoices: Gov.cn. Nationwide rollout, 20-digit number, invoice content, red-letter process/72 hours, verification.
3. Civil Code of the People's Republic of China: Supreme People's Court. Performance (Article 509), payment (Articles 626/628), unclear terms (Articles 510/511).
4. National VAT Invoice Verification Platform: State Taxation Administration. Invoice verification entry.