Release a NetSuite payment run only after the selected obligations, payee details, approvals and bank file agree. Preserve evidence of who approved the population and who released it to the bank. Successful file generation is one checkpoint; bank acceptance and settlement require their own confirmation.
This checklist is for AP and treasury teams preparing an ordinary supplier payment run. It does not replace bank-specific submission instructions, signing authority or your payment policy. Adapt the checks to the actual Electronic Bank Payments configuration and any connected payment service.
Oracle's Electronic Bank Payments overview explicitly says the SuiteApp generates payment files but does not transmit them to banks. If your process sends files automatically, identify the separate integration or service responsible for that step.
Write down who selects bills, reviews exceptions, generates the file, submits it and releases it at the bank. Include an absence cover arrangement. A process that depends on one person's memory is difficult to operate safely during holidays or urgent runs.
Define the run's scope: paying entity, funding account, payment currency, value date, eligible vendors and payment method. Those details belong on the review cover sheet and should match the file and bank submission.
Verify that selected bills are approved under the applicable process, due for payment and free of unresolved holds. Review credits, prepayments, partial payments and disputed amounts before calculating the net amount to send.
Compare the selected population with prior runs and pending files. A bill may be unpaid in one view while a previous submission is still awaiting confirmation. Do not add it to a new run until the earlier outcome is established.
Review unusual inclusions and exclusions. High-value bills, first payments to suppliers, overdue critical suppliers and manual additions deserve attention. A filtered list can omit an important bill because of entity, date or bank setup; completeness is a business review as well as a technical check.
Review new suppliers and bank-detail changes since the last successful payment. Confirm that independent verification and approval are complete. The payment reviewer should see the evidence status without needing unrestricted access to full banking details.
Check the intended recipient bank when a vendor has multiple bank records. Ensure that entity, currency and payment format align with the selected route. Do not assume the default bank is always the right destination for every bill.
If a change is unresolved, hold the affected payment and document the next step. An urgent due date does not make an unverified bank change safe. Escalate through the approved payment authority rather than bypassing the review.
Oracle's payment-batch approval routing documentation distinguishes approval based on bill amount, vendor amount or total batch amount. Confirm which basis the account uses and whether it matches the intended authority policy.
A reviewer approving individual bills may not have approved the final cash requirement of a combined batch. Conversely, a batch approval should not substitute for evidence that each underlying obligation is valid.
Record the approval reference and version of the selected population. If bills, amounts, payees or value dates change afterward, determine whether reapproval is required. The approved list and released file must describe the same payment instruction.
AP prepares 28 vendor payments totaling 184,000. After approval, a supplier sends a new bank instruction and another bill is added for 9,500. The new file would contain 29 payments totaling 193,500.
The earlier approval no longer describes the final population. The changed bank details require verification, and the additional obligation requires the appropriate approval. Treasury should not rely on the original 184,000 sign-off simply because the run name is unchanged.
The corrected package identifies the revised total, changed vendor and added bill. This hypothetical case illustrates the need for a clear version boundary between preparation and release.
Capture the number of payments, total value by currency, funding account, execution date and file identifier. Where the bank format includes its own control totals, compare them with the approved run evidence using a supported validation method.
Inspect a risk-based sample of beneficiaries and amounts, including all changed banks and unusually large payments. Do not edit a generated payment file casually to repair a mismatch. Determine whether the source data, template or selection is wrong, then regenerate through a controlled process.
Keep the final file in an access-controlled location. Retain a checksum or other immutable identifier if your operating design supports it, so the released file can be tied to the approved artifact. That is a recommended control, not a claim of a built-in NetSuite checksum feature.
Oracle's manual Electronic Bank Payments procedure describes generation through a Payment File Administration record and review of processing status before downloading the file. Confirm the result and investigate any error before proceeding.
Do not treat a confirmation email as the only evidence. Retain the relevant record and generated file reference. If an operator sees an uncertain timeout, first check whether a file and associated payments already exist.
Before submission, verify the bank's permitted value date, cut-off and file format. Those requirements come from the bank and selected service; they should not be inferred from a generic ERP guide.
At the bank, verify that the uploaded count, amount and funding account match the approved file. Use the authorized signers and retain the bank acknowledgement or submission reference.
Track acceptance, rejection, partial rejection and settlement separately. A successful upload may establish only that the bank received a file. Assign ownership of the result review so no run is left at “submitted” indefinitely.
Reconcile the eventual cash movement to the payment records and investigate returned payments. Customer or supplier notifications should accurately describe the stage reached; avoid communicating settled payment merely because a file was generated.
The minimum package contains scope, selected bills, exceptions, bank-change verification status, approvals, control totals, final file reference, bank acknowledgement and reconciliation evidence. Restrict access according to the sensitive data it contains.
After each run, record issues that required manual intervention. Repeated changes after approval, missing credits or unclear bank acknowledgements are process improvements to address before increasing automation.
For batch controls and account-specific processing issues, CuriousRubik's NetSuite support services can help review the configured flow and evidence gaps.
Oracle says the SuiteApp generates files but does not transmit them. Identify any separate bank integration or service used in your implementation.
It may change operationally, but the final instruction must remain within valid approval. Recheck material changes to amounts, bills, destinations and dates.
Keep payment count and value by currency, funding account, value date and file identifier. Reconcile them across the approved population, generated file and bank acknowledgement.
No. Track the bank's acceptance and settlement evidence separately, including partial failures and returned payments.
Hold the affected payment and escalate through the approved authority. Resolve the verification before sending money to the changed destination.