Hand over the pending case, including the evidence needed to decide its next action.
Imagine an illustrative Friday invoice whose submission response arrives after a Monday NetSuite cutover. If the response calls for a correction, which team owns the next step? A separate pending-document queue needs an explicit owner, an evidence snapshot and a permitted next action. Moving an invoice balance into NetSuite does not establish what happened to an earlier submission attempt or who should handle its correction.
The difficult cases often sit across the changeover: an invoice created in the old billing system, a response received after the migration extract, or a credit prepared after the original system becomes read-only. A handover ledger lets finance and support manage those cases without assuming that every open item should be submitted again.
The method below is for a Singapore business whose applicable GST InvoiceNow obligations and submission route have been confirmed. It complements the wider integration cutover and rollback plan; its focus is the ownership of individual invoice-data cases.
Define three boundaries before selecting a go-live time
The accounting boundary specifies which transactions and balances enter NetSuite. The submission boundary identifies the system responsible for each invoice-data population. The support boundary says which team investigates a case after go-live. These boundaries may use different rules, but their relationship must be written down.
For example, finance might migrate an open receivable while the old reporting route retains responsibility for its pre-cutover invoice-data submission. That is a possible design, not a universal recommendation. The tax owner and solution providers must confirm it is supported and preserves the applicable deadlines.
Record the boundary in a form an operator can apply: legal entity, document family, relevant date basis, original source and current responsible route. Avoid “old invoices stay in the old system” unless the team has defined what “old” means for a document issued before cutover but corrected afterward.
Also define the final evidence snapshot time and the reconciliation procedure for events arriving afterward. A snapshot is a dated observation, not proof that the queue has stopped changing.
Rehearse five cases in one illustrative queue
Assume a fictional business rehearses a handover of 20 documents. The following states are management labels for the exercise, not claimed status names in NetSuite, an access point or IRAS. The team maps them to the actual source responses before using the ledger.
Four documents have not been submitted. The responsible route must be identified from the approved boundary. Record the reason they remain pending and the deadline-relevant period. A finance owner confirms the source data is ready; a technical owner confirms the supported transmission path.
Three have an attempt but no verified final response. Keep the attempt identifiers and latest observations. The next step is to establish the outcome through the supported status-reconciliation or provider investigation process. Do not interpret a blank local response as evidence that nothing was received.
Ten have a verified accepted outcome for the relevant reporting stage. Preserve the response reference, source and time checked. They remain in the handover evidence so the destination team can recognise them and avoid treating them as new submissions. Confirm what “accepted” actually means in that route. A technical accepted response does not approve the invoice’s tax treatment.
Two were rejected. Keep the rejection evidence, proposed correction and owner. A data error may belong to billing; a mapping problem may belong to the integration team. The ledger should identify the supported correction process without assuming that a new business invoice must be created.
One has a correction pending. Link it to the original business document and earlier outcome. Finance decides the accounting and tax treatment; the solution team confirms how the appropriate correction or adjustment is represented. Cutover should not sever that relationship.
The counts total 20. The purpose of the exercise is to prove that every document has one current owner and a defensible next action. It does not establish a universal target for accepted or unresolved items.
Make the ledger usable during a real incident
Each row needs the legal entity, original document number, original system ID, destination record reference if one exists, relevant period, current owner and next action. Add the transmission or document UUID available in the actual route, the latest observed status, its source and the time checked.
Keep the evidence reference separate from the operator's conclusion. “Provider response retrieved at 10:15” is an observation. “No further submission required” is a decision that needs an authorised reviewer and a defined meaning for the response.
Include the source document version or an equivalent version reference supported by your systems. If the customer address or tax detail changes after the snapshot, the team needs to know which version was submitted and which version is awaiting review.
Use a single case owner even when several teams contribute. That owner coordinates the work; it does not give them authority to make tax decisions, alter accounting records or bypass the provider's supported correction process.
Reconcile again after the handover snapshot
Oracle documents a GST InvoiceNow Reporting function that reviews outbound transactions and refreshes their latest IRAS status through the access point. Its availability depends on the relevant preference and solution setup. Where this is the selected route, include a demonstrated reconciliation in the cutover rehearsal.
Other components in the architecture may hold their own attempt histories. Confirm how those histories remain accessible and how the new support team can obtain them. Do not assume that credentials, registrations, UUIDs or queues can be transferred between providers through an undocumented operation.
After the snapshot, compare newly received responses and changed source documents with the handover ledger. Record the changes as updates to existing cases rather than silently replacing the baseline. This preserves the explanation for why a case moved from uncertain to resolved after the new system went live.
A network-delivery event, an application acknowledgement and an IRAS status can describe different stages. The status dictionary should identify which one each field represents before finance uses it as completion evidence.
Decide what can proceed and what needs escalation
Use the following release questions:
- Does every candidate document appear in the ledger or in a documented excluded population?
- Can each uncertain attempt be investigated after the old team's access changes?
- Is there one responsible route for every pending submission and correction?
- Have the tax and finance owners assessed unresolved items against actual obligations and deadlines?
- Can support distinguish migration records from documents requiring a new reporting action?
- Has an authorised person accepted each remaining exception with a specific next step?
An exception sign-off is an internal management decision. It does not waive a statutory requirement. If a deadline is at risk, escalate it to the responsible tax and finance owners with the affected documents and evidence, rather than changing dates or hiding the queue.
Finally, test one post-cutover correction against a pre-cutover document before retiring access. IRAS record-keeping expectations continue through a software change, so preserve the original document and its associated evidence in a retrievable arrangement. The project is ready to hand over this workstream when the operating team can explain each remaining case without relying on the migration developer's memory.
