GST F5 Preparation for Singapore E-commerce SMEs: 21 Days to Q3 Close

If you are GST-registered and selling through marketplaces today, the single most useful thing you can do for your Q3 GST F5 is to export and tag your 9.9 transaction data this week, while every order, fee and refund is still individually identifiable. The Jul–Sep quarter closes on 30 September — 21 days from today — and the returns, cancellations and payout adjustments generated by a sale day take roughly that long to settle. GST F5 preparation for Singapore e-commerce SMEs fails not because the form is difficult, but because sale-day volume arrives faster than the systems recording it, and by the time anyone reconciles in October the detail has been collapsed into net payout figures that cannot be unpicked. This is a data-capture problem with a three-week window, and it is solvable now.

Why does a sale day make your quarterly GST return harder than the rest of the quarter?

An ordinary trading week produces transactions that follow one another slowly enough for your normal process — however manual — to keep up. A sale day compresses several weeks of order volume into 48 hours, and it does so at the exact moment your team has the least attention to spare for record-keeping.

Three specific distortions follow. First, order-level detail gets replaced by aggregate: many SMEs only ever record the platform payout, which is already net of commission, transaction fees, shipping subsidies and buyer refunds. Second, the timing spreads: an order placed on 9 September may ship on the 11th, be returned on the 22nd, and appear as a payout deduction in October. Third, the exceptions multiply — cancelled orders, partial refunds, promotional discounts absorbed by the platform rather than by you. Each of these is unremarkable in isolation. Several hundred of them, discovered in the last week of September, is a fortnight of someone's life.

Which 9.9 numbers does your F5 need that your sales dashboard is hiding?

Your marketplace dashboard is built to answer a merchandising question — how much did we sell — not a compliance question. The figures your quarterly return depends on generally sit one layer below it.

The practical list to extract before the data ages:

• Gross sales value per order, before platform deductions — not net payout. Output tax is generally calculated on what the customer paid, not what the platform remitted to you.
• Local versus overseas customer split, where you ship internationally, so zero-rated supplies are separable rather than reconstructed from shipping labels in October.
• Platform fee invoices with the GST treatment visible. Check whether each platform issues fees through a Singapore GST-registered entity showing a GST registration number, or from an overseas entity. The treatment differs, and it is not something to guess in the last week of the quarter.
• Refunds and cancellations with their original order date attached, so a credit note can be matched to the supply it reverses.
• Imported services and low-value goods purchased during your pre-sale ramp — overseas ad spend, SaaS subscriptions, freight platforms.

If you cannot produce these five exports today without someone manually opening order screens, that is your Q4 systems fix, and it is a smaller one than it sounds.

What should you actually build in the next 21 days?

Not an accounting system. The realistic scope for three weeks, alongside a 10.10 and 11.11 run-up, is a reconciliation layer that sits between your marketplace exports and whatever your bookkeeper uses.

The minimum viable version is a scheduled export from each sales channel into a single staging table, keyed on order ID, with columns for gross value, each fee category, refund status and settlement date. It does not need to post journals. It needs to make one question answerable in seconds: for any figure on the return, which orders make it up? That is the question that consumes the fortnight when it cannot be answered.

Build it once and it serves three deadlines, not one: this quarter's F5, the Form C-S groundwork due before 30 November, and the InvoiceNow/PEPPOL transition that will eventually require your transaction data to be structured rather than exported as PDF.

How do you stop the mid-September returns wave from landing in the wrong period?

Returns from a 9 September sale peak between the 16th and the 25th — comfortably inside the quarter, which is the good news. The failure mode is that the refund is processed by the platform and shows up as a payout deduction, while your books still carry the original sale at full value and no credit note exists.

Fix the workflow rather than the arithmetic. Every approved return should generate a credit note referencing the original invoice at the moment of approval, not at month-end. If your RMA process lives in a spreadsheet or a WhatsApp thread, connect the approval step to whatever issues your documents, even if the connection is one webhook. The volume between now and 30 September is exactly the load test you need — and the same wave will arrive at four times the size after 11.11, when the quarter boundary at 31 December is far less forgiving.

What does a clean Q3 close look like operationally?

By 25 September you should be able to hand your accountant: gross sales by channel with local and overseas separated; a fee schedule per platform with GST treatment identified; a credit note listing tied to original invoices; a purchase listing flagging imported services; and a reconciliation between total payouts received and total gross sales less deductions, with any variance explained rather than plugged.

That package is not a bigger workload than most SMEs already do in October. It is the same workload, done while the underlying data still remembers what it was — and done by a scheduled export instead of by a person clicking through order screens on a Saturday.

This is operational workflow design, not tax advice. Your GST treatment, registration position and filing obligations should be confirmed with your tax agent or directly against IRAS guidance.

Frequently asked questions

We only sell through marketplaces and the platform handles the money. Do we still need order-level data?
Yes. The platform settles a net amount to you, but your return is generally concerned with the value of your supplies to customers and, separately, with the fees the platform charges you. Those are two different transactions that arrive as one number. Without order-level detail you are reporting a figure you cannot substantiate if it is ever queried.

Our 9.9 volume was manageable this year. Is this worth building before 10.10 and 11.11?
That is precisely the argument for building it now. September gives you a real but survivable dataset to test against, and roughly eight weeks before 11.11 produces three to five times the volume. A reconciliation process first attempted under 11.11 load will not survive it.

How long does a basic marketplace reconciliation layer take to stand up?
For a business on one or two platforms with existing API access, a working staging export and variance report is typically a few days of build rather than a project. The time is usually spent agreeing what each fee category means and where returns are approved — not on the integration itself.