FX Settlement and Reporting for Chinese Exporters: What the ERP Must Handle

The gap between the invoice and the bank

An export order is priced in one currency, invoiced in that currency, collected in it, and eventually converted into RMB to pay wages and suppliers. Every step in that chain has an exchange rate attached, and the rates are not the same. The quotation rate used when the order was priced, the rate on the invoice date, the rate at which the bank actually converted the receipt, and the period-end rate used to revalue whatever is still outstanding are four different numbers. An ERP that stores one and assumes the others will produce a book profit that cannot be reconciled to the bank statement.

This is not a technicality. For an exporter running on thin margins, exchange movement between quotation and settlement can equal or exceed the entire margin on the order. If the system cannot say, per order, what the rate was at each stage and where the difference was posted, then nobody in the business knows whether an order made money until an accountant reconstructs it. And because the export rebate computation depends on the FOB value in RMB, the FX model also feeds the refund — so an error here propagates into tax.

What settlement actually involves

It helps to separate four events that are often spoken of as one. Receipt is the money arriving in your foreign-currency account. Settlement is the conversion of foreign currency into RMB — which may be immediate, partial, or deferred depending on how the business manages its currency position. Revaluation is the period-end restatement of open foreign-currency balances at the closing rate, producing unrealised gains or losses. Reporting is the obligation to make your cross-border receipts visible to the foreign-exchange authority in a form that reconciles to your trade.

Exporters commonly treat these as a treasury concern handled outside the ERP. That works until someone asks a simple question — what is our uncollected foreign-currency exposure by customer — and the answer requires an export from the accounting system, a download from the bank portal, and a pivot table. At that point the ERP has become a recorder of history rather than a source of truth.

The rate problem, precisely

Four rates matter and each has a legitimate role, which is why a single-rate design fails.

• Quotation rate — the rate used when pricing the order. It is a commercial decision input, not an accounting one, but it determines whether the order is profitable.
• Booking rate — the rate used to record the receivable and the revenue when the invoice is issued. This is the accounting basis for the transaction.
• Settlement rate — the rate the bank actually applied when converting. The difference against the booking rate is a realised exchange gain or loss.
• Closing rate — the period-end rate used to revalue balances still open. The difference against the booking rate is an unrealised gain or loss, reversed or adjusted when settlement eventually happens.

The design requirement is that all four are stored and attributable, and that the posting rules are explicit. The most common defect is that the settlement rate overwrites the booking rate, so the realised difference silently disappears into the revenue line and the P&L never shows an exchange result at all. The second most common is that revaluation is computed but never reversed, so gains and losses accumulate in a way that double counts once the receivable is collected.

Partial settlement is the normal case, not the exception

Textbook examples settle a receivable in one transfer. Real exporters receive deposits, staged payments against shipment milestones, and final balances after acceptance — often with deductions for bank charges, quality claims or freight adjustments. Each receipt consumes part of the receivable at its own rate. The residual keeps being revalued at each period end until it closes.

This is where a system without proper allocation logic breaks. If receipts are applied to invoices in a lump and the rate difference is calculated on the total, the per-instalment economics vanish and disputes over a deduction cannot be traced to the specific shipment. The requirement is allocation at the line or instalment level, with the rate captured per receipt, so that at any moment the system can state the open balance in both currency and RMB, at the rate it was booked and at the current rate.

There is a control question hiding here as well. A deduction taken by the customer — a claim, a bank charge, an unagreed shortfall — is not an exchange difference, and posting it as one is a small fraud risk and a real audit finding. The system should force a reason code on any receipt that does not fully clear the expected amount.

Which rate the rebate actually uses

The rebate computation converts a foreign-currency value into RMB, and the rate it uses is not the rate at which you happened to settle the money. The relevant conversion is conventionally the rate on the date the transaction is recognised for tax purposes — in practice the invoice or declaration date — using the published rate of that day or the established monthly convention, depending on the applicable rules and the taxpayer's adopted approach. The settlement rate may be entirely different, and the difference is an exchange result rather than a rebate adjustment.

This creates a specific data requirement that most ERP models miss: the system must be able to derive the tax-basis RMB value independently of the actual cash receipt, and to explain the difference between the two. If the ERP only stores the settled amount, the rebate computation cannot be reproduced from the system and will be rebuilt in a spreadsheet — usually by the one person who knows which rate convention the company uses. That is a single point of failure sitting directly on top of the largest recoverable asset in the business. Store the conversion rate, its source, and the date basis on the transaction, and the computation becomes auditable rather than remembered.

Hedging, and why most exporters do not

Forward contracts and options are the textbook answer to currency exposure, and many small and mid-sized exporters do not use them, for reasons that are rational rather than careless: the instruments require credit lines, documentation and a treasury function, and a company whose orders are individually small may find the administrative cost exceeds the benefit. What such companies do instead is a natural hedge — receiving foreign currency and paying foreign-currency suppliers or costs from the same account, so that only the net position is converted.

Natural hedging is legitimate but it has an accounting consequence: settlement stops being a single event per invoice and becomes a netting of receipts and payments across currencies and periods, which is considerably harder to reconcile to individual shipments. The ERP must therefore support matching a payment to a payable across a currency pool without losing the shipment-level link, or the rebate and audit files lose their fund flow leg. If your business nets receipts against payments, test that specifically in a demo — it is a common gap and it manifests as an unreconciled balance that grows every month.

The domestic side of a foreign-currency business

An exporter is not only exposed on the sales side. Domestic suppliers are paid in RMB, wages are paid in RMB, and the factory's costs have no currency exposure at all until the moment of conversion. The business therefore carries an implicit bet: it earns in foreign currency and spends in RMB, which means a strengthening RMB compresses margin across the entire cost base while a weakening one expands it. Companies that price orders off a single quotation rate, without reviewing it as the rate moves, are running that exposure unmanaged and usually unaware of it.

The system contribution here is modest but real: a quotation rate stored per order, compared against the booking and settlement rates, produces a per-order exchange result that management can actually see. Aggregate that across a quarter and you have the true currency contribution to profit, separated from commercial performance. Without it, a good quarter and a lucky quarter are indistinguishable, which is how companies conclude that a rate move was strategy.

What a mismatched receipt tells you

When a bank receipt does not match the invoice it is supposed to settle, the gap is information rather than an inconvenience. A shortfall of a few percent that recurs with one customer usually reflects a commercial deduction the sales team agreed verbally — a quality claim, a promotional allowance, a freight share. A shortfall that appears once and is never explained may be a bank charge, or may be a sign that the payment came from a party other than the buyer, which is a question a tax reviewer will ask about the authenticity of the transaction.

A payment from a third party is the case worth designing for explicitly. Group treasury arrangements, factoring, and payments routed through a trading affiliate all produce receipts from an entity that is not the invoiced customer, and the explanation is usually legitimate. But the explanation has to exist in the record, attached to the receipt, or the transaction looks unusual to anyone reviewing it cold. The ERP should provide a named field for the payer when it differs from the customer, plus a reason, rather than forcing the user to choose between mis-recording the customer or leaving an unexplained variance. Small design decisions like this determine whether an audit file is self-explanatory or requires a narration.

There is a useful diagnostic in the pattern of mismatches across a portfolio. If most receipts match exactly and a handful do not, the exceptions are individual commercial events and belong in a work queue. If most receipts are short by a small amount, the pricing or the incoterm is being applied inconsistently, and the fix is upstream in how orders are quoted. The ERP's contribution is to make the distribution visible; without a settlement matching view, both situations look identical at month end — a suspense balance that someone clears with a journal.

Reporting and the monitoring relationship

China's foreign-exchange framework for goods trade is built around monitoring rather than per-transaction approval: enterprises operating foreign trade are subject to a registration and classification regime, and their cross-border receipts and payments are matched against their trade data. The practical consequence for an exporter is that the consistency between what customs saw, what the bank received and what the tax authority refunded is itself the control. Discrepancies in that triangle surface as queries, and repeated discrepancies affect how closely you are monitored.

The ERP's role is not to file on your behalf but to be able to produce, per shipment and per period, the receipt that corresponds to it. If a receipt arrives with a reference that does not map to an invoice, that is a reconciliation item that should appear on a list, not a mystery discovered at year end. The related discipline of matching three documents is covered in export tax rebate ERP software for China; the same matching logic applies here with the bank receipt as the third leg.

What to require from the ERP, concretely

The following is a defensible minimum specification for an exporter with meaningful foreign-currency volume. Each item is testable in a demo with your own data.

• Multiple rate types stored per transaction, with the rate source and date visible and auditable.
• Receipts allocated to invoices or instalments, with per-receipt rate capture and automatic realised gain/loss posting.
• Period-end revaluation of open balances with automatic reversal at the start of the next period.
• A live exposure view: open foreign-currency receivable by customer, by currency, in original and RMB amounts.
• Reason codes for short receipts and deductions, so exchange differences and commercial deductions are never conflated.
• Export of settlement data in a form that reconciles to the bank statement without manual assembly.

One more requirement deserves mention because it is easy to overlook: the rate source itself must be recorded. Whether the company uses the central bank's published central parity, a commercial bank's rate, or a monthly average convention, the basis has to be consistent across entities and visible on the transaction. Two departments using two different rate sources is not a rounding difference — it produces two versions of the same receivable, and the version that reaches the tax filing is whichever one was used last. Naming the source in the transaction record makes the convention auditable rather than customary.

A system that meets these turns a monthly reconciliation headache into a report. The wider finance picture — including how these postings land in the general ledger and how they interact with costing — is covered in ERP finance capabilities. For groups with several overseas entities, the same logic extends to intercompany balances, where an unmanaged FX exposure becomes a consolidation problem rather than a treasury one; see multi-entity consolidation for Chinese groups going overseas.

The cost of treating FX as an accounting afterthought

There is a version of this problem that is purely financial and a version that is operational. The financial version is unbudgeted exchange loss: a 3% move on a 5% margin order is a 60% swing in profit, and it is invisible if the rates are not recorded. The operational version is slower and worse: finance spends the first week of every month rebuilding a reconciliation that the system should have maintained continuously, sales prices orders without knowing what currency movement does to them, and management reviews a profit number that is really an accounting artefact.

Neither problem is solved by a bank portal or a treasury spreadsheet, because both live at the seam between trade data and money. That seam is exactly where an export-capable ERP earns its cost. If your current system cannot show you, right now, what you are owed in foreign currency and what it is worth in RMB at today's rate, that is not a reporting gap — it is a missing control.