An overseas brand’s first China store needs more than a payment terminal and an invoice button. A customer can pay through two methods, request a company invoice and return one item several days later. The POS, payment service, invoicing platform and finance system must all describe the same business event without pretending that they complete it at the same moment.

China’s nationwide rollout of fully digital electronic invoices took effect on 1 December 2024. For implementation, local finance must confirm the applicable issuing entity, invoice categories, tax treatment and correction procedures. The integration team then turns those approved rules into transaction fields, statuses and acceptance tests.

Keep four records connected and distinct

RecordQuestion it answersKey references
POS sale or returnWhat was sold or returned, at what agreed price?Order, receipt, line item and return identifiers
Payment or refundWhich funds moved and through which channel?Payment transaction and refund identifiers
Tax invoiceWhat was issued, corrected or reversed?Original invoice, request and correction identifiers
Financial postingWhat was recognized in which accounting period?Voucher, batch, account and posting date

These records should be traceable from the original order. An invoice can still be processing after payment succeeds; a refund can finish before a required red-letter invoice is issued. A single “completed” flag cannot explain the outstanding work.

Overseas headquarters may need transaction-level information, summarized reporting or both. That reporting scope should be agreed separately from the local legal invoice workflow.

Agree five rules before building the interface

  1. Issuance trigger: decide whether a request begins at checkout, after customer confirmation or through a later customer process. Define the accepted transaction states.
  2. Buyer information: distinguish individual and company requests, validate required fields and collect only information needed for the process.
  3. Invoice allocation: define whether and how orders can be split, combined or partially invoiced. The number of payment methods should not automatically determine the number of invoices.
  4. Amounts and tax mapping: agree discount allocation, item descriptions, tax classification, rates and rounding with local finance.
  5. Dates: retain the business date, invoice date and accounting posting date separately. Do not overwrite one to make a daily total match another.

Also define who can correct buyer information, approve exceptional requests and resume a failed process. A technically valid interface still needs a workable store procedure.

Assign responsibilities across local and headquarters systems

The POS owns the retail transaction and initiates the agreed requests. It should not independently determine tax policy. The payment channel reports payment and refund outcomes. The invoicing service handles issuance and returns the original or red-letter document results. Local finance or ERP owns accounting treatment and reconciliation.

Headquarters ERP or BI receives the agreed operational and financial information. A connection to global ERP does not make that ERP the issuer of China tax invoices. Required local fields and processes need an explicit home in the architecture.

Follow a mixed-payment sale through a partial return

Use an illustrative sale with item A at RMB600 and item B at RMB400. The customer pays RMB600 through WeChat Pay and RMB400 by card. Under the test policy, one RMB1,000 invoice covers the purchase.

On day three, the customer returns item B. The agreed test policy refunds RMB400 to the card. If the original invoice has already been issued, the required correction process handles RMB400 against that invoice, leaving RMB600 as the net invoiced amount.

The records should show the original RMB1,000 sale, both payment legs, the original invoice, the RMB400 return, the refund result and the invoice correction. They should also preserve each event’s actual completion time. The example’s refund destination is a specified test rule, not a universal rule for all mixed-payment returns.

A second partial return must respect cumulative limits. The total returned quantity, refunded amount and corrected invoice amount cannot exceed the applicable original basis.

Determine the actual invoice status before correcting it

The invoice has not been issued

Check the service’s actual state. A timeout in the POS does not prove that issuance failed. If the request truly remains unissued, the process may cancel or amend it according to the service rules. If the invoice was issued despite the timeout, use the applicable issued-invoice correction process.

The invoice has been issued

China’s rules provide a red-letter invoice process for relevant returns, errors and allowances. The required confirmation flow depends on the original invoice’s use and accounting-confirmation status. Where the other party’s confirmation is required, track it as a separate step rather than treating a request as a completed correction.

Keep the original invoice reference, correction request, confirmation status and final red-letter document. Local finance should approve the process for the actual invoice type and transaction.

A late result arrives after a refund

Process the result against the original request and the order’s event history. A late “issued” callback must not overwrite the refund state or cause the return to disappear. It should trigger the next required invoice action or enter an exception queue.

Use stable request identifiers for retries. A genuine correction should create a new linked event; replaying the same event with different amounts creates ambiguity and weakens duplicate prevention.

Explain daily differences instead of forcing equal totals

POS net sales, payment net receipts and net invoiced amounts may differ on a particular day because the events complete on different dates. Payment fees also need separate treatment from gross customer payments.

Reconcile by order and event before comparing period totals. For each difference, show the amount, reason, current state, responsible team and expected resolution time. Examples include a pending invoice, a failed refund, an awaiting-confirmation red-letter request or a transaction posted in a later accounting period.

A report that flags differences without assigning follow-up responsibility does not close the process. The exception should remain open until its evidence supports resolution.

Eight acceptance scenarios for a first China store

  1. Individual request: issue the appropriate invoice and retrieve it from the original sale.
  2. Company request: test valid and invalid buyer information, the correction process and the authorized operator.
  3. Mixed payment: use two payment methods for one sale and demonstrate the agreed invoice allocation.
  4. Cross-day issuance: issue after the sale date and explain the daily reconciliation difference.
  5. Timeout after acceptance: let the service receive the request before the POS times out; recover the result without a duplicate invoice.
  6. Refund before the issuance result: deliver a late result and show how the system identifies the required next action.
  7. Partial return: connect the item, refund and invoice adjustment and enforce cumulative limits.
  8. Full return after period close: retain the original records and show the approved current-period adjustment and outstanding confirmations.

Acceptance evidence should include identifiers, statuses, amounts and timestamps from the POS, payment service, invoice service and finance interface. Mark genuinely inapplicable steps clearly; an empty field should not hide an untested requirement.

Define the China store layer before connecting headquarters

PEKON Smart Retail System and the International Brands Entering China solution provide a basis for discussing local POS, payments, returns and reconciliation alongside headquarters integration. The particular invoice provider, red-letter automation, tax-field checks and accounting interfaces should be confirmed for the project.

Ask the supplier to classify each requirement as standard capability, configuration, integration, additional development or unavailable. A generic statement that a platform “supports electronic invoicing” does not resolve who owns a failed correction or a cross-period difference.

Information sent to overseas headquarters is a separate design decision. Define the necessary fields, level of detail and access controls alongside the applicable data requirements; do not assume the complete local invoice or customer record must be copied overseas.

Frequently asked questions

Does a successful payment mean the invoice has been issued?

No. Payment and invoice processing have separate results. Link them through the order and retain both statuses.

Do two payment methods require two invoices?

Not automatically. Follow the approved invoice allocation rules for the transaction.

Can the POS simply cancel an issued invoice after a return?

The issued document must follow the applicable correction procedure, including a red-letter invoice where required. Determine the original status first.

Must all daily totals match exactly?

Not when events complete on different dates or have different reporting bases. Every difference should still be explainable and assigned for follow-up.

Can headquarters ERP replace the local invoice workflow?

Only an expressly designed and compliant local process can perform that role. Receiving China sales data in a global ERP is not equivalent to issuing China tax invoices.

Official references

See the State Taxation Administration announcement on fully digital electronic invoices and its red-letter invoice guidance. These sources define the regulatory process; the project acceptance plan should show how the chosen systems implement the applicable requirements.