Migrate open receivables and payables by establishing the unpaid position at the approved cutoff and preserving the identifiers, dates, currencies and applications needed to settle it correctly. Coordinate the detailed open items with the opening ledger so the same balance is not posted twice. Finance should approve the representation and reconciliation before users begin collections or payments.
This work is more specific than importing a trial balance. An accounts-receivable total does not tell the collections team which invoice is overdue, and an accounts-payable total does not identify which supplier document should be paid. The new account needs a reliable relationship between settlement activity and the accepted opening position.
Choose one cutoff and a reconciled source aging or open-item schedule. Record the report's date basis, entity, currency and inclusion rules. Investigate differences between the subledger and general ledger before using either as the migration authority.
Include credits, prepayments, unapplied cash and disputed items where they affect settlement. A file containing only positive invoices can overstate what is collectible or payable. Conversely, netting unrelated documents can remove information needed to apply a later receipt or payment correctly.
Separate document balance from document status. A disputed invoice may remain open but should follow a different collection process. A held vendor bill may contribute to the payable balance without being eligible for the first payment run.
Preserve the original customer or vendor reference and source document identity. Repeated invoice numbers across suppliers or entities need additional context so the target does not confuse different obligations.
The migration design may use residual open amounts or a tested reconstruction of gross documents and historical applications. These approaches can both require additional decisions about dates, document presentation and historical retrieval. Do not mix them casually within the same population.
If only a remaining amount is loaded, retain the original amount and prior settlement evidence through an approved reference or archive. Users should understand why the target document differs from the original customer or supplier document.
If gross documents and payments move, verify their supported sequence and application links. For invoice and customer-payment importing, invoices must exist first, and payment association uses the invoice's internal or external ID rather than an assumed unique transaction number.
Have the responsible accountant approve migration accounts, opening journals and currency treatment. There is no universal entry pattern that can be copied safely into every account. The design must explain the combined effect of the detailed documents and ledger load.
Map each imported posting to the opening-position reconciliation. Imported transactions behave as real transactions; an imported vendor bill with inventory items can affect inventory. Do not assume a migration label makes a transaction operationally inert.
Determine which account balances are established by the open documents and which remain to be established through other approved opening entries. Retain a bridge that shows the intended combined position without double counting.
Test the design with a small representative sample before loading the full population. Inspect transaction detail and actual posting results. A file that imports successfully can still use an inappropriate item or account.
Keep correction authority separate from technical loading. If a balance differs, the loader should investigate and present evidence, not add an unexplained adjustment simply to match the trial balance.
Define how original invoice date, due date, posting date and migration date will be represented. They serve different purposes. Replacing every due date with the cutover date can make old debt appear current and change payment priorities.
Verify payment terms, holds, disputes and collection attributes that influence the next business action. Some source values may not map directly to the proposed target process; those differences need an approved operating decision.
Keep transaction currency and base-currency values distinct. Reconcile each within its approved currency basis and exchange-rate treatment. A matching base total can conceal errors among documents in different currencies.
Confirm customer and vendor subsidiary relationships and required reference records before loading. A valid supplier name alone does not establish the correct entity, currency or account context for its bill.
A fictional customer has an original invoice of 1,000 currency units, with 400 already paid before cutover. The unpaid invoice amount is 600. A separate unapplied credit of 100 also remains available. The net receivable position is 500, but the open invoice and credit remain distinct settlement items until an approved application occurs.
The team chooses an accountant-approved residual migration model. It loads the 600 open invoice position and the separate 100 credit according to the tested design, preserving original references and aging information. It does not also recreate the 400 historical payment against the residual invoice.
The reconciliation checks 600 - 100 = 500 at the customer level and confirms the accepted posting bridge to the ledger. It also verifies that a future receipt can be applied to the intended invoice without losing the credit's separate identity.
If the team instead chose to migrate the original 1,000 invoice and the 400 payment, it would need the supported application sequence and a different detailed load plan. Combining that gross-document approach with another 600 residual invoice would duplicate the obligation.
Use supported record types and stable unique identifiers. For new vendor-bill imports, the source identity must consistently identify the record across its lines. Keep the human supplier invoice reference distinct wherever the design requires it.
Review item and expense lines, tax-related fields and exchange-rate mappings against the account's feature set and selected form. Do not assume that a template copied from another account has the same available fields or financial behavior.
Test multiline and mixed cases. Include a credit, partial settlement, unusual due date, foreign-currency document and a held item where these exist in scope. Avoid proving the entire design with one simple domestic invoice.
Control the import-trigger settings deliberately. Required validation should remain effective, while unintended notifications or downstream actions must be prevented through an approved tested design. Disabling all automation is not a substitute for understanding its purpose.
Compare source and target identifiers, document counts, open amounts and aging categories. Summarize by entity, customer or vendor, currency and control account as appropriate. Explain differences rather than netting them away.
Check the excluded population too. Fully settled documents should not become newly payable or collectible. A historical invoice imported for reference needs a design that does not accidentally put it into an active payment queue.
Test the next settlement step in a safe environment. Apply a representative receipt or payment, inspect the remaining balance and verify the accounting result with finance. A correct opening report alone does not establish that the ongoing process works.
Keep payment-file generation, bank submission and customer communications behind their own authorized release gates. Migration acceptance does not automatically authorize moving money or contacting customers.
Capture receipts, payments, credits and adjustments between the accepted extract and cutover. Reconcile their effect before the first production collection or payment cycle. A late payment can create a costly duplicate if the target still treats the invoice as fully open.
Retain the source schedules, mapping version, target references, posting bridge and exception decisions. Protect personal and financial details in the evidence pack and preserve access only for authorized reviewers.
For difficult open-item populations, CuriousRubik's NetSuite support services can help prepare the account-specific reconciliation and settlement tests. Finance remains responsible for the approved accounting treatment and final acceptance of the opening position.
No. It establishes account totals but not the individual obligations, dates, credits and applications needed for collection and payment. The detailed open items must reconcile to the approved ledger position.
That depends on the approved representation. A residual model and a gross-document-plus-applications model require different load plans. Avoid combining them in a way that duplicates the obligation.
Do not assume so. For supported invoice/customer-payment import, association uses internal or external IDs. Preserve stable identities and validate the actual route's reference rules.
It supports the intended aging and settlement meaning. The migration design should distinguish original dates from cutover and posting dates rather than make all outstanding documents appear newly due.
After finance accepts the detailed and ledger reconciliation, final deltas are resolved and the relevant settlement, communication and authorization controls have passed their separate checks.