When a NetSuite bank feed appears to miss transactions, prove the missing population before importing a replacement file. Compare posted bank activity with import history and all relevant matching states, then repair only the confirmed gap. Reimporting a broad date range without an overlap check can create a second problem while leaving the original cause unresolved.
This guide focuses on missing import windows and duplicate-safe repair. It is distinct from resolving ordinary reconciliation differences after data is complete. Bank Feeds, custom bank connectors and direct integrations have different timing and recovery behavior; identify the actual source before following a procedure.
Oracle's Bank Feeds setup considerations state that the SuiteApp imports posted transactions, not pending transactions. They also note that bank posting schedules and provider timing can affect availability, and advise waiting at least 24 hours when transactions appear missing.
That guidance is a diagnostic starting point, not a reason to ignore a material close deadline. Confirm whether the transaction is fully posted and downloadable at the bank, then use the approved escalation or manual evidence process where timing matters.
Record the bank's transaction date, posted date and the time of the last available import. Time-zone differences can make a transaction appear to belong to the missing day when the provider considers it part of another window.
Specify bank account, NetSuite account, currency, connector, format profile and date interval. Avoid reporting “the bank feed is broken” when only one account or one day is affected.
Obtain the bank statement or posted-transaction export for that interval through an authorized route. Retain opening and closing balances where available, along with transaction count and totals for credits and debits.
Compare individual transaction identifiers, dates and amounts. A matching net total is insufficient: one missing credit and one missing debit can offset. Keep the bank's original identifiers rather than generating a new arbitrary number that cannot be traced back.
Oracle's Viewing Imported Banking Data documentation points to Banking Import History for import status and troubleshooting, and to the appropriate matching or expense view for the imported data type.
Review matching, excluded and other relevant states available in your account. A line absent from the active work queue may have been matched or deliberately excluded rather than omitted from the import.
Check account mapping and filters as well. A wrong account selection, date filter or entity scope can hide a present transaction. Confirm the actual record before changing the connector or uploading more data.
Record the last successful import, later attempts, error messages and any configuration change around the gap. Determine whether the issue affected connectivity, parsing, account mapping or only transaction availability.
A successful import status does not necessarily prove the expected date interval was complete. Compare its content with the independent bank population. Conversely, one failed attempt may have been followed by a successful retry.
Review the connector's own documentation for supported refresh and history behavior. Do not borrow a third-party connector's retry interval or on-demand feature and describe it as universal Bank Feeds behavior.
A bank export contains 37 posted transactions for Monday and Tuesday: 12 credits and 25 debits. The initial NetSuite matching view shows 31 of those transactions. Four missing lines belong to a failed Tuesday import; two others are already present under an excluded state.
The confirmed repair population is four lines, not six and not the whole two-day file. The team records the exclusions separately and confirms whether they were intentional.
Before importing the four lines, the owner checks whether the automatic feed might still backfill them. The repair plan defines how to identify and handle overlap if that occurs. This hypothetical example shows the evidence sequence without assuming any specific provider's duplicate-detection guarantee.
First consider the connector's supported retry, refresh or backfill procedure. Confirm the date range and whether it reuses source transaction identifiers. Do not disconnect and reconnect the feed casually without understanding the history window and mapping consequences.
Where a manual import is appropriate, Oracle's Bank Data Import guidance distinguishes automatic and manual routes. Use the supported parser and configuration for the actual file format and account.
Prepare a gap register listing the exact bank transactions to restore and their identifiers. If the source export contains overlap, determine how the selected import path handles it before uploading. Do not assume that every parser or integration recognizes duplicates identically.
Importing statement data and creating an accounting transaction have different effects. A missing bank line may correspond to a payment already recorded in the ledger. Repairing the import should not create another bill payment or customer receipt.
Before using any automatic transaction-creation rule, identify the expected existing transaction and why it was not matched. A missing-data incident is a poor moment to expand broad creation rules without controlled testing.
If both bank data and ledger activity are missing, treat them as two linked issues. Finance should approve the necessary accounting entry based on the underlying transaction evidence, while the bank-data owner restores import completeness.
Recompare counts, credit totals, debit totals and individual references against the bank export. Confirm that every repaired line appears once in the appropriate account and that no previously present line was duplicated.
Then perform matching and statement reconciliation under the normal process. Preserve the repair log, import reference and explanation of any remaining timing items. Do not close the incident merely because the upload succeeded.
If the automatic feed later backfills the same window, inspect the result and resolve any duplicate bank lines through the supported process. Follow the applicable approval and retention rules before deleting or excluding records.
Create a routine completeness check for accounts material to the business: last successful import, unexplained inactivity, transaction counts and bank control totals where available. Define the owner and escalation route.
Use an independent statement or bank population at close even when daily feeds usually work. Automation reduces manual collection effort but should not become its own sole proof of completeness.
For custom connectors, mapping problems or recurring gaps, CuriousRubik's NetSuite integration services can help review the source-to-import path and recovery controls.
It may still be pending or unavailable for provider download, or there may be an import or mapping issue. Confirm posted status and review the specific account's import evidence.
Only after understanding overlap and duplicate handling. Prefer a confirmed gap population and a supported repair route with explicit verification.
No. Compare the imported population with independent posted bank data, including separate debit and credit totals and transaction identifiers.
Yes. Inspect the relevant states and filters before concluding the source transaction was never imported.
When the bank window is complete, each line is represented once, ledger ownership remains correct and the normal matching and reconciliation checks are finished.