The first step in an export tax rebate is looking up the correct rebate rate. It appears straightforward: enter the HS code, read the result. In practice two problems recur. The rate found does not match what is actually refunded, or the code cannot be found at all.
The cause in most cases is not the policy but the lookup convention. The rebate rate is not a static figure you can retrieve by typing a code.
Mistake one: querying with the customs declaration code directly
The rebate rate attaches to the commodity code of the exported goods, but there are several layers: the code used for customs declaration, the code used for the rebate filing, and the code ranges referenced in the policy document.
Frequently a ten-digit code works for declaration but has no matching rate record in the filing module, because:
- The code was added or adjusted this year and the rebate system has not synchronised
- The code falls into a non-rebatable or exempt category, so no rate is recorded
- The description attached to the code does not fully match the declared goods
Confirm the code and description referenced in the current rebate policy first, then confirm the code version in the system. Only when both align does the result mean anything.
Mistake two: ignoring code version and effective dates
HS codes change through periodic revisions, merging, splitting, addition and repeal. Querying with an outdated code can return a code that no longer exists, or the rate of a subheading that has since been split off.
Timing is the more common trap. Rate adjustments carry explicit effective dates, and the rate applicable depends on the date of export, not the date of filing. Where a shipment spans an adjustment date, the export date governs. This is especially error-prone around annual transitions and periods of frequent policy adjustment.
Mistake three: treating the rate as the refund amount
The refund is not the export value multiplied by the rate. Several deductions sit in between:
- The tax base differs: manufacturers use the FOB value, trading companies use the purchase amount
- Whether the input VAT credit is complete and fully deductible
- The gap between the levy rate and the rebate rate requires an input transfer-out
- Documents must be complete; incomplete portions cannot be filed
So a rate of 13 percent refunding less than thirteen percent of export value is normal, not an arithmetic error.
The rate is a policy parameter; the refund is a calculation result. Treating them as the same thing is the most common starting point for rebate errors.
The correct sequence
- Establish the correct classification first; a wrong code invalidates everything after it
- Confirm the rebate policy in force for the period, noting effective dates and scope
- Query the rate for that code in the rebate filing system, checking the code version in use
- Compare policy document and system result; where they differ, the policy document governs, confirmed with the competent tax authority
- In the calculation, separate tax base, input deduction and transfer-out to arrive at the actual refundable amount
Why documentation still matters
A correct rate is necessary but not sufficient. Filing requires a complete set: customs declaration, export invoice, foreign exchange receipt, transport documents, and an agency certificate where applicable. Documentation must be retained for the prescribed period. If it is incomplete or cannot be produced during an inspection, refunds already paid may be recovered.
The rebate risk does not sit only at filing. It also sits at the post-audit stage, which is routinely overlooked.
Summary
The difficulty in rebate rate queries is not the querying but the conventions. Correct code, correct version, correct date, correct tax base. When all four align the figure is usable; when they do not, the figure is wrong even if it looks precise.