The feed already arrives. Someone still has to post it.
NetSuite can import a bank statement, and most finance teams running it already have that switched on. The day's lines land in the account overnight without anyone touching anything.
That was never where the work was. The work is deciding what each line actually is. Which customer that deposit belongs to. Whether a debit is a vendor payment, a bank fee or a loan draw. Whether a transfer between two accounts is a sweep that needs an intercompany journal on both sides. Then creating the record, then applying it.
Plenty of teams do this every morning, and do it well. It's just hand work: read the line, decide what it is, make the record, apply it, move to the next one. A few hundred lines a month, every month, forever.
Read the file, classify the line, post the record
A statement file arrives, by upload or straight from the bank. BankSync parses it, works out what each transaction is from its type code and description, and creates the NetSuite record that belongs to it.
Customer payments
Deposits matched to the customer and applied to open invoices, with anything it can't identify held for review rather than guessed.
Vendor payments
A bill payment when exactly one open bill matches exactly. Otherwise an A/P journal that sits on account until someone picks the bill.
Sweeps and transfers
Both legs paired across accounts. Intercompany journals on OneWorld, plain bank transfers on a single-entity account.
Fees, interest, everything else
Mapped from the statement's own type codes to the accounts you nominate, so the long tail posts too instead of piling up.
Underneath, each supported statement format parses into one canonical shape, so the posting engine never has to know whether the day arrived as BAI2 or MT940. Adding a format means writing a parser, not touching the part that posts to the ledger.
Three problems that decide whether you can trust it
Giving a bank line a name
A statement doesn't arrive once. It gets re-uploaded by hand, pulled again from the bank's site later in the day after more activity has landed, re-run after a failure. So every line needs a name that's identical each time that line appears and different from every other line.
Generating one doesn't work. A sequence or a fresh ID would come out different on every upload and match nothing, so the name has to be derived from the line itself. Where the bank supplies its own reference that's the best possible ingredient, because the bank is guaranteeing it. Where there's no reference, and at some banks there almost never is, the line's own content stands in, including the customer reference field. That's where a cheque number lives, and without it two cheques for the same amount are indistinguishable.
The name is also qualified by account and statement date, which we learned from real files. One bank reuses a sweep's reference the next day for the matching credit, five times across eight months of statements. Keyed on the reference alone, an eight-figure sweep credit would have been silently discarded as a duplicate of the previous day's debit.
And when two lines genuinely are identical in every field the bank gave us, they get counted rather than collapsed. Three identical payments stay three. If the duplicate check itself can't run, the engine says so plainly in the log and processes everything, because quietly dropping real transactions is the worse failure.
The cash has already left the bank
That's the fact the whole design turns on. By the time a line shows up on a statement, the money has moved. Whatever the software decides, the general ledger needs to agree with the bank.
So BankSync posts a bill payment by itself only when the case is unambiguous: the vendor routes to A/P, there's exactly one open bill, it's for exactly that amount, and the subsidiary is switched on for it. Several open bills, an amount matching none of them, or no bill yet, and it doesn't guess.
What it doesn't do is stage the line and post nothing. That's the tempting alternative and it's wrong, because real cash movements then sit invisible in the general ledger until somebody happens to work the queue. The uncertain ones post to A/P against cash instead. The money is off the books where it belongs, the payment sits on account, and it applies cleanly once someone picks the bill.
Not overriding the controls you already have
Anything that posts to the general ledger on its own has to fit the controls a finance team already runs, rather than quietly replacing them. This is the first question every controller asks, and it deserves a real answer.
BankSync doesn't set approval status on the journals it creates. It leaves the field alone so NetSuite's own default, and whatever approval workflow you run, decide what happens next. Forcing it either way overrode a client's own workflow, which is exactly the kind of thing nobody notices until an audit.
Auto-creation is a switch per subsidiary and per transaction type, so you can turn on sweeps and leave vendor payments off until you trust them. Every record it posts links back to the bank line it came from and the run that created it, so the trail goes from the journal in the GL to the row in the file.
The books reflect the bank, every morning
The day's activity is read and posted without anyone typing it in. What's left is a short queue of lines the engine declined to guess at, which is the part that actually needs a person, and a dashboard showing the cash position it all adds up to.
BankSync started as client work and became a product. It's the reason the rest of this site talks about custom development the way it does: the same engine that reconciles one company's bank accounts is the one now running for others.
Worth a look if you're posting bank activity by hand
The product site has the detail, including how it handles multiple institutions, what the review queue looks like, and what it costs.
See BankSync on real bank activity
A 30-minute demo running against a real statement file in a real NetSuite account.