Return Historical Vendor Bills to Review Before EFT in NetSuite

Repair script quotes, inspect custom approval reset guards, and compare a historical bill with an unchanged current EFT candidate before submitting any payment.

The quick answer

For a vendor bill approved through a custom script or workflow that permits a reset, return the selected historical bill to Pending Approval, then check the same EFT selection again. Vendor Bill approvalstatus is 2 for Approved and 1 for Pending Approval. Keep an unchanged current bill as a control. Standard UI approval does not offer this reset, and changing the field alone does not restart an approval workflow.

Before you start

Confirm the intended account's approval model supports returning an approved bill to Pending Approval. Test the complete transition in a sandbox, including workflow state, Next Approver, notifications and accounting impact. The code step below uses a local API model to show the guard logic and its result; it does not create a NetSuite script deployment.

Restrict the candidates to open, entirely unpaid bills with no credits, prepayment applications, payment batches, files or other payment-processing reservations. Confirm that period restrictions and role permissions permit the update. The example takes a conservative approach and stops for a closed, A/P-locked or all-locked period. Pending Approval is non-posting under standard bill approval; do not assume that resetting an already-approved bill removes its existing GL impact. Verify the account's actual GL and workflow behavior.

The example uses Operating Checking, 2000 Accounts Payable, USD and Example Supply US throughout. Both bills use the same vendor EFT setup and compatible bank details. The cutoff is 2026-10-01, exclusive, based on the bill date.

1. Compare the two EFT candidates

Open EFT - Bill Payments. Choose Operating Checking and 2000 Accounts Payable. Leave the Pay boxes clear.

The displayed example lists current bill CUR-8102 first, dated 2026-10-10, then historical bill LEG-8101, dated 2026-09-10. Only the second bill is before the cutoff. The screen uses month/day/year formatting.

Displayed row order: current CUR-8102 first, historical LEG-8101 second. The cutoff is October 1.

In that same row order, Amount and Amount Remaining are 500.00 for CUR-8102 and 1,200.00 for LEG-8101. Both are entirely unpaid. These adjacent crops come from the same result; enlarge either for the complete table, including the clear Pay boxes.

Same rows: CUR-8102 has 500.00 due; LEG-8101 has 1,200.00 due. Enlarge for the identifiers and clear Pay boxes together.

2. Repair the JavaScript string delimiters

Open the example in the local JavaScript Workbench and click Run local example. Typographic quotation marks around the first approvalstatus string produce a SyntaxError. The output also reports No updates committed.

The local parser rejects typographic quotes. Enlarge to see the source and No updates committed message.

Replace both typographic delimiters with ASCII single quotes. The check must read:

if (String(get('approvalstatus')) !== '2') return;

Keep the script tags in one valid JSDoc block, with each tag on its own line:

/**
 * @NApiVersion 2.1
 * @NScriptType MassUpdateScript
 */

3. Run the guarded example

Inspect the checks before rerunning. The example loads each selected bill, requires Approved (2), skips bill dates on or after 2026-10-01, and requires the custom custbody_reset_permitted checkbox. That checkbox records account-specific permission to use this reset; it does not override NetSuite permissions or a workflow.

The source also requires a positive amount remaining equal to the total, no Payment Hold, and a posting period whose closed, aplocked and alllocked checks are false. Role permissions, workflow ownership and payment-processing reservations still need separate account validation before deployment. This example is not a complete production implementation.

After the checks, the source sets the field to Pending Approval:

bill.setValue({ fieldId: 'approvalstatus', value: '1' });
The source fragment uses 1 for Pending Approval. Enlarge to inspect the complete call and preceding guards.

Click Run local example again. The executed source returns 8101 to Pending Approval and skips 8102 because it is outside the cutoff. The result is Updated: 1 · Unchanged: 1. A rerun skips the already-pending historical bill.

One historical bill changed; the current bill was skipped by the date guard.

4. Inspect the saved historical bill

Open LEG-8101. Its Approval Status is now Pending Approval. The amount remains 1,200.00; enlarge the image to check the reference, amount, date and posting period together.

LEG-8101 now shows Pending Approval. Enlarge for its 1,200.00 amount, reference, date and period.

Payment Hold stays clear. The approval status changed; this example did not set a payment hold.

Payment Hold is still clear; approval is the control changed in this example.

In the intended account, verify system notes, the actual workflow state, Next Approver and expected GL impact. The approval field alone does not prove that review routing or notifications ran. An On Create-only workflow does not retrospectively start when an existing bill changes. Routing needs update-based initiation or an explicit supported workflow transition or action.

5. Compare EFT selection without submitting

Return to EFT - Bill Payments. Choose the same bank and A/P account. Keep the subsidiary, currency, vendor bank setup, role and other eligibility conditions constant.

Only CUR-8102 remains in the displayed result. In this example, LEG-8101 is absent after its approval status changed. Confirm that the account's EFT page filters on approval eligibility and that no other eligibility condition changed.

Only the current reference remains in the same EFT selection.

The current bill still has 500.00 as both Amount and Amount Remaining. Its Pay box remains clear and Payment Amount is blank; enlarge for the complete row.

CUR-8102 still has 500.00 due. Enlarge to check its clear Pay box and blank Payment Amount.

Number of Transactions is 0 and Total Payment Amount is 0.00. Do not click Submit. A payment batch or file is not needed to verify this selection result.

No transaction is marked for payment. Do not click Submit.

Common questions

Can I reset any approved vendor bill to Pending Approval?

No. Standard UI approval does not provide that reversal. Oracle documents a script or workflow exception for bills approved through that model. Confirm the particular account permits the transition, then test its workflow and accounting consequences. The example's custom checkbox is a guard, not authority to bypass approval rules.

Why did changing the default approval status leave historical bills in EFT selection?

The default controls newly created bills. It does not rewrite existing approval values, workflow states or payment-processing reservations. Existing bills need an explicitly supported review path, with a carefully scoped candidate list and validation of downstream payment activity.

Why does copied code produce an illegal-character error?

Typographic quotes such as ‘ and ’ are not JavaScript string delimiters. Use ASCII single or double quotes, preserve valid multiline JSDoc tags, and resolve parsing errors before processing records. The local example shows a parser error before any bill is processed. Runtime failures after execution starts need separate per-record logging and recovery.

Does setting approvalstatus to 1 restart my approval workflow?

It changes the transaction's approval field when the account permits the update. It does not establish a workflow state, assign an approver or restart an On Create-only workflow. Configure and test a supported update or explicit workflow transition, then inspect the actual state and routing results.

Is Pending Approval equivalent to Payment Hold?

No. Under standard bill approval, Pending Approval prevents the bill from posting and being payable; custom workflows require their own behavior checks. Payment Hold blocks payment of an otherwise approved bill. Choose the control that matches the accounting and review requirement, and verify the relevant payment list with all other eligibility conditions held constant.

Supporting sources