8 Marina View, #28-01 Asia Square Tower 1, Singapore 018960
Monday–Friday, 9:00 AM – 6:00 PM
GST & E-Invoicing Readiness
GST readiness for a single entity is mostly a setup task. For a group with several registrations, it becomes a process question: which entity files, on what schedule, from which data, and how the consolidated pack reconciles to each return.
InvoiceNow-aligned e-invoicing adds a second set of checks — how invoices move in and out of each registered entity. Below is what to verify before a migration date is agreed.
What the check settles, entity by entity
GST registration
3
registrations, one group
Filing cycles
2
quarterly & monthly mixed
Returns from ledger directly
1
the answer worth holding
Inbound invoices needing entity allocation
0
if capture knows the entity
Group pack tied to all returns
1
one reconciled group view
Each GST-registered entity in a Singapore group files its own returns. A group with three registrations carries three filing obligations — and those cycles may not agree: one entity on quarterly, another on monthly. The consolidated pack is what sits across them, and it has to reconcile to each return without a spreadsheet round-trip.
Four checks worth running
Take last quarter's returns and ask a simple question: was each one produced from the ledger directly, or assembled by hand? If it was assembled, your team is producing the GST data — the platform is only holding the entries. That distinction decides whether a stack is ready for multi-entity filing at all.
An entity making both taxable and exempt supplies carries apportionment rules. The software either handles them, or it makes the outside calculation clean. Where the vendor says the accountant handles it, that is a legitimate answer — but it tells you the platform stops short of the return.
The questions that matter are per entity: is each registered entity set up to send and receive, does the integration know which entity issued the invoice, and how are inbound supplier invoices captured into the right books. Groups running document capture alongside the ledger need the capture layer to know the entity — otherwise the extraction saves entry time and creates allocation time.
A GST-ready group ties its consolidated pack back to each entity's filing: revenue in the group accounts reconciles to the sum of entity revenue adjusted for intercompany eliminations, and each entity's taxable supplies reconcile to its return. Prepared monthly, that is a small task. Reconstructed at year end, it is a large one.
Where compliance software stops short
The standard worth holding vendors to
Compliance features are rarely the reason groups change platforms. They are often the reason a migration gets delayed. A stack that consolidates beautifully and files GST awkwardly will still consume finance-team time every quarter, and that time is worth weighing explicitly when you compare platforms for your structure.
No platform removes the need for an accountant's review of a GST return. What a good one buys you is the difference between a review and an assembly job.
What to hold a vendor to
Ask for the demonstration on your own entity structure, not on a sample company. Two questions usually separate a stack that is genuinely ready from one whose compliance work has been quietly moved to your team:
Question one
Can the system produce a GST return per registered entity from its own data, with correct treatment for standard-rated, zero-rated and exempt supplies, and with the supporting transaction listing behind it?
Question two
For a mixed-supply entity, does the software apply apportionment, or can the outside calculation be cleanly attached to the return?
Migrating without breaking filings
If the group is changing ledgers, the migration has to preserve the GST audit trail across the changeover. Three things carry that: cut-over dates aligned to a GST period boundary, opening balances agreed per entity, and a documented treatment of anything spanning the boundary. The practical advice is simpler than the mechanics — avoid a mid-period cut-over, and avoid migrating two entities in the same month.
Step one
Move each entity's ledger at a GST period boundary, not inside one. That preserves the audit trail, keeps the final return on the old system clean, and gives the first filing on the new system a full period of its own.
Step two
Opening balances are agreed entity by entity, signed off before the first close. What lands in the group pack needs to trace back to each agreed figure, so the reconciliation does not depend on someone's memory six months later.
Step three
Let each entity's first close on the new system be reviewed before the next one moves. Slower in the calendar, and substantially less likely to produce a filing error you discover two quarters later.
A note on timing
If a migration date is already on the calendar, work backwards from the GST period boundary before confirming the date. A single entity cut-over usually fits; a whole group's rarely does.
Questions groups ask
Four questions that come up before a group commits to a stack or a migration date.
Yes. GST registration and filing are per entity, so a group with three registrations has three filing obligations and one consolidated pack to reconcile against them. The schedules may not even match: one entity can be quarterly while another files monthly.
Ask for a demonstration on your own entity structure, and ask whether each registered entity's return can be produced from the ledger directly. If the answer is manual extraction, your team is producing the return — the platform is holding entries.
It changes how invoices are sent and received per entity. The checks are whether each registered entity is set up for it, whether the sending identity respects which entity issued the invoice, and whether your document capture layer knows which entity an inbound invoice belongs to.
Align the cut-over to a GST period boundary, agree opening balances per entity, and avoid moving two entities in the same month. Sequence migrations so each entity's first close on the new system can be reviewed before the next entity moves.
