Get started
All articles
NetSuiteSFTPBAI2NACHA

NetSuite BAI2 and NACHA over SFTP - without middleware

Connect NetSuite to bank SFTP for BAI2 statements and NACHA payments using native tools and a simple mailbox - without costly middleware.
DocEvent Engineering·Sep 1, 2026·9 minute read

NetSuite can import BAI2 bank statements and send NACHA payment files over SFTP using built-in tools. In many implementations the missing piece isn’t middleware - it is a stable SFTP endpoint between the bank and NetSuite.

This guide covers the two file formats, what NetSuite handles natively, where direct bank connections commonly fail, when an SFTP mailbox is the simpler answer, how to run one on DocEvent and what the bank will ask you.

The two files, briefly

BAI2 is the file behind your bank’s “previous day reporting” or “information reporting” service: balances and transactions per account, one comma-delimited text file per day, defined by the Cash Management Balance Reporting Specifications (published 1987, maintained by ASC X9 since 2008). It looks like this:

01,021000018,BIGCORP,260901,0430,1,80,10,2/     file header
02,BIGCORP,021000018,1,260831,,USD,2/           group header
03,4501234567,USD,010,1250000,,,015,1175000,,/  account: balances by type code
16,115,250000,,,,LOCKBOX DEPOSIT                one transaction
16,495,75000,,,,WIRE OUT ACME LTD               another
49,2550000,5/                                   account trailer: control total
98,2550000,1,7/                                 group trailer
99,2550000,1,9/                                 file trailer

The type codes (010, 015, 115, 495 above) come from the specification’s list; which ones your bank populates is a question for the bank, not a software setting. And every level ends in a trailer record with control totals, so a BAI2 file collected mid-upload fails arithmetic loudly - a real advantage over CSV, where a truncated file parses fine.

NACHA travels the other way: the batch of ACH payments (vendor payments, payroll, direct debits) your ERP originates and your bank submits into the ACH network. The format is fixed-width, 94 characters per record: a file header (1), batch headers (5) carrying the company and SEC code, one entry detail (6) per payment with optional addenda (7), and batch/file control records (8/9) with entry counts, hash totals and dollar totals.

Both formats predate APIs and were built for batch transmission windows, which is why the delivery mechanism your bank offers first is SFTP. It remains a perfectly good contract: a file, a directory, a schedule, and totals to prove the file is whole.

What NetSuite already does without help

NetSuite ships, at no extra licence cost, SuiteApps that speak SFTP in both directions.

Statements in

  • The Bank Feeds SuiteApp - the aggregator route, and the right answer for small accounts at well-covered banks. Its documented limitations: up to 20 linked accounts, a manual refresh at most every 60 minutes, and Oracle’s own note that not every institution can be accessed reliably this way. If you are weighing “bank feed app vs bank SFTP”, this route stands or falls on how well the aggregator happens to work with your bank.
  • Manual import - download BAI2 / CAMT.053 / OFX from the banking portal and import it. Fine as a fallback; as a process, it is somebody’s job forever.
  • The Auto Bank Statement Import (ABSI) SuiteApp - the one this article is about. ABSI connects to an SFTP server and imports statement files automatically every day: a format profile with “SFTP Connectivity”, server details and credentials, a parser, and a file name pattern so it knows which files to take. Standard parsers cover BAI2 and MT940; the Bank Statement Parsers SuiteApp adds CAMT.053, OFX/QFX and CSV, and a custom plug-in covers anything else. This route supports far more accounts than the aggregator (Oracle documents up to 500).

Payments out

  • Electronic Bank Payments + the SFTP Connector SuiteApp. Electronic Bank Payments generates the NACHA (and other EFT) files; the SFTP Connector transfers them from designated File Cabinet folders to a folder on the bank’s SFTP server, moving each transferred file to a processed folder as a record.
  • A scheduled SuiteScript using the N/sftp module for anything the connector doesn’t cover. Its fine print: strict host-key checking (you supply the server’s host key up front), password GUID / SSH key / API secret authentication, and a 100 MB upload cap - none of which a NACHA file will ever hit.

So NetSuite can pull statement files on a schedule, parse BAI2 natively, and push payment files out - all built in. The remaining problems are operational.

Where direct bank connections fail

Almost never at parsing, and almost never at the protocol. Five specific problems:

1. The bank pushes; NetSuite only pulls

ABSI is a client: it connects out and collects files. Plenty of banks host an SFTP server for that. But many transmission setups - very commonly for BAI2 previous-day feeds - work the other way: the bank’s gateway connects out and pushes files to a destination you nominate. If you have no SFTP server to nominate, you are stuck at four fields on a bank form: host, port, username, directory.

2. IP allowlisting, in both directions

Bank transmission teams pin connections to known addresses: the IPs their gateway pushes to, and often the IPs of any client that connects in. NetSuite is a multi-tenant SaaS, and Oracle’s documentation is explicit that its IP addresses are dynamic and can change without notice; the suggested workarounds are resolving outboundips.netsuite.com on the firewall, or SSH keys instead of address pinning. Some bank security teams accept that. Many hand the form back.

3. The bank’s mailbox is not an archive

Banks purge their transmission directories after days or weeks, and ABSI imports the parsed transactions rather than keeping your raw files. When an auditor asks for the actual statement file from 14 months ago, or a parser problem makes you want to re-import a quarter, someone needs to have kept the original bytes.

4. NetSuite is not the only consumer

The same daily BAI2 file feeds treasury workstations, cash forecasting and data warehouses. ABSI consumes it into NetSuite, full stop; a second consumer means a second transmission setup with the bank, another fee and another month of paperwork.

5. Nobody is watching the pipe

A scheduled import that quietly stops is worse than no automation, because everyone has stopped checking. Files arrive late, arrive half-written while the poller reads them (the truncation race), or stop arriving at all. Outbound is sharper: when payroll has to be at the bank by the cutoff, “the script ran” is not the same as being able to show the file was delivered.

An integration platform does solve most of these - at the cost of per-connection pricing, another platform to learn, and your bank files flowing through a third party’s storage. The actual requirement is smaller: a reliable SFTP endpoint, simple routing, and a record of what moved.

The mailbox pattern

The simplest pattern is to put a plain SFTP endpoint - one you control, on storage you own - between the bank and NetSuite.

Statements in · BAI2 / CAMT.053
Your bank
cash management / treasury
bank pushes each morning - or a scheduled pull collects
The mailbox
/bank/statements/
NetSuite Auto Bank Statement Import polls, filename pattern
NetSuite
parses BAI2, matches, reconciles
Payments out · NACHA / ACH
NetSuite
Electronic Bank Payments builds the file
SFTP Connector (or N/sftp) uploads
The mailbox
/bank/payments/
routed on to the bank's SFTP, with retries and a log
Your bank
ACH origination
One SFTP endpoint, on a bucket you own. The raw files are the archive, and anything else that needs them - treasury, a data warehouse - reads the same directories.
The round trip. Neither the bank nor NetSuite changes how it works - each talks plain SFTP to a mailbox you control, and the mailbox’s storage is your archive.
  • The bank gets what its form asks for: a hostname, a dedicated user, a directory, fixed addresses, a host key. If the bank hosts instead, a scheduled pull collects from them into the same directory - the NetSuite side cannot tell the difference.
  • NetSuite gets a server it can always reach: ABSI polls the mailbox with a filename pattern; the SFTP Connector drops NACHA files into the outbound directory.
  • The raw files land in your own bucket, so the archive and support for additional consumers come with it, without touching the bank setup again.
  • The two sides decouple: the bank’s 04:30 push and NetSuite’s import schedule no longer need to agree on anything, and each hop is small enough to log and alarm on honestly.

Running the mailbox on DocEvent

The concrete version, with capabilities current as of September 2026. The mailbox itself is a Simple FTP Service: a managed SFTP endpoint over your own S3, Azure Blob, GCS or S3-compatible bucket, with the properties the bank form asks about:

  • A dedicated user for the bank, confined to its own directory, and a separate user for NetSuite so the two sides’ credentials stay independent.
  • Static IP addresses per region for the bank’s allowlist paperwork, and a per-service firewall with allow and deny lists to pin the endpoint to the bank’s published ranges. (NetSuite’s own addresses are dynamic, so protect its user with strong credentials or an SSH key rather than by IP - Oracle’s recommendation anyway.)
  • A published, stable SSH host key fingerprint - what N/sftp’s strict host-key checking demands, and what the bank’s transmission form has a box for.
  • An audit log of every login and every file touched, on the service’s Logs tab.

If the bank hosts and you must pull, a Channel with an SFTP Pull source dials out to the bank’s server on your schedule: a filename glob (take BAI2_*.txt and nothing else), minimum-age and stable-size gates against collecting a file mid-write, a verify-before-complete check, and delete-or-move on the bank’s side once collected. The same channel can deliver the file to the mailbox and to any other destination - the fan-out from gap four.

Outbound, the shape inverts: NetSuite uploads the NACHA file to the mailbox, and a channel picks it up from your bucket (bucket event to SFTP delivery) and carries it to the bank, with automatic retries, a per-file routing log of every attempt, and failed deliveries parked for reprocessing. When the payroll question comes - did the file reach the bank? - the answer is a log entry, not a shrug.

To be clear about when you need none of this: if your bank hosts an SFTP endpoint, accepts ABSI’s connection, and NetSuite is the only consumer, point ABSI straight at the bank and buy nothing - from us or anyone else. The mailbox earns its place when the bank will only push, when addresses must be pinned, or when you need the archive, the fan-out or the delivery evidence. Two scope notes: DocEvent moves and records your bank files but does not parse or validate BAI2 or NACHA - that stays NetSuite’s job. And if your bank PGP-encrypts files on top of SFTP’s transport encryption (some do), agree with the bank where decryption happens before NetSuite parses - a pass-through mailbox deliberately does not hold your private keys.

Stand up the bank mailbox in an afternoon
An SFTP endpoint on your own bucket, with the static IPs, host key, user isolation and audit log the bank’s transmission form asks about - and Channels to pull from the bank or deliver to it.

What the bank will ask you (and what to ask them)

The slow part is not software - it is the bank’s transmission onboarding, which runs on forms and test cycles. Arrive with answers:

  • Direction, per file type. Do they push statements or host them for pickup? Do they require payment files pushed to them? Mixed answers are common.
  • Host, port, username, authentication. Password or SSH key - and if key, where to send the public half. Have your endpoint’s details ready for their half of the form.
  • Host keys, exchanged both ways. Their fingerprint for your client config; yours for theirs.
  • IP allowlists, both ways. The addresses their gateway pushes from, and the addresses you connect from.
  • Directories, filename masks, and after-processing behaviour. What the files are called, which directory each lands in, and how long they keep files - delete, move, or age off.
  • Timing. When the previous-day file is published, and the cutoffs for payment submission. Your pull schedule and NetSuite’s import sit downstream of both.
  • PGP. Whether files are encrypted on top of SFTP, and if so, key exchange and where decryption happens.
  • The test cycle. Ask what a passing test looks like and who confirms it, so it doesn’t become a three-week email thread.

The decision, compressed

  • Small bank footprint and the Bank Feeds SuiteApp covers your institution reliably? Use it and stop reading.
  • Bank hosts an SFTP endpoint, accepts ABSI’s connection, NetSuite is the only consumer? Point ABSI at the bank. No mailbox, no middleware.
  • Bank will only push; or requires pinned client IPs NetSuite can’t give; or you want the raw-file archive; or statements feed more than NetSuite? Run the mailbox: bank ↔ SFTP endpoint on your own storage ↔ NetSuite’s built-in SFTP tools.
  • Sending NACHA files with real deadlines? Put the delivery on rails that log every attempt, so “did it reach the bank?” has a recorded answer.
  • Whatever you build: keep the original bytes, and treat the bank’s onboarding checklist as the critical path.

References

Related reading: Truncated files on SFTP and FTP - how a poller collects a file that is still being written - and File transfer audit trails - what a delivery record has to contain to count as proof.
All articles