Sage Intacct Bank Statement Import: Convert PDF Statements to OFX and CSV for Bank Reconciliation

What file formats does Sage Intacct accept for bank statement import?

It depends which of the two import experiences you use. The classic import for reconciliation reads CSV and QIF. The newer Bank transaction assistant file import adds XLS, XLSX and OFX on top of those, which is why it is the more flexible route for anyone converting statements. PDF is not accepted by either.

The table below sets out what each format needs before Intacct will take it.

Can Sage Intacct import an OFX file?

Yes, through the Bank transaction assistant file import. Sage documents OFX as one of the formats the assistant supports in addition to the CSV and QIF the classic process reads. Once the file is in, the transactions match automatically against Intacct transactions using the rules in the account's rule set, and appear on the Banking cloud tab for that account.

OFX tends to be the least fragile route for anyone loading statements by hand. It sidesteps the classic import's fixed column names entirely, and it carries a unique identifier per transaction, which gives matching a real basis rather than relying on date and amount alone. There is more on what sits inside the format on the OFX file format page, and the bank statement to OFX converter covers producing one from a PDF.

How do I import bank transactions into Sage Intacct?

For the Bank transaction assistant, go to Cash Management, then All, then Transactions, and select Add next to Bank transaction import files. You choose the bank account or credit card account the file belongs to, upload it, and confirm the date order during the review step. Imports cover one account at a time, and a long period can take a few minutes to process.

The classic route is a different menu: Cash Management, then All, then Reconciliation, then Bank, where you select an account and choose Import. Access to the assistant depends on subscribing to Sage Cloud Services with the Bank transaction assistant file import option enabled, and on Cash Management permissions for bank transactions covering list, add, delete and view. If the menu item is missing, that is usually the reason rather than anything to do with the file.

What columns does the Sage Intacct classic CSV import need?

Seven columns in a fixed order: POSTING_DATE, TRANSACTION_TYPE, DOCUMENT_TYPE, DOCUMENT_NUMBER, PAYEE, AMOUNT and DESCRIPTION. Of those, only POSTING_DATE, TRANSACTION_TYPE and AMOUNT are mandatory, and dates must be formatted as MM/DD/YYYY. Getting the order or the names wrong is the usual reason a file that looks correct is refused.

Worth weighing before you build a process around it: Sage documents the classic import experience as going away in a future release. A monthly routine built on that exact template will need rebuilding at some point, whereas the assistant reads OFX and spreadsheets without demanding those column names at all. If you are setting this up fresh rather than maintaining something that already works, the assistant is the more durable choice.

Why does importing remove my bank feed transactions?

Because that is the documented behavior. If the account uses a bank feed, importing a CSV or QIF file unmatches and removes unreconciled bank feed transactions on that account. It is not a bug and there is no warning that makes it obvious in advance, which is what makes it costly the first time somebody meets it mid-reconciliation.

Two habits avoid it. Check whether the target account has a feed before importing anything into it, and when you do import, upload only the delta, meaning the new transactions within the statement ending date, rather than re-uploading a full period that overlaps what the feed already brought in. Both of these take moments and prevent the kind of rework that costs an afternoon.

Loading history the bank feed cannot reach

This is the usual reason for converting statements in the first place. Bank download screens typically serve about 90 days of activity while the statement archive goes back years, so an Intacct implementation, an account migration or an audit request that touches prior periods runs straight past the edge of what a feed can provide. The statements themselves are the complete record.

For that kind of catch-up, convert the monthly PDFs as a batch rather than one at a time. Up to 50 files go into a single upload, and when every document belongs to the same account you can merge them before extraction, so twelve monthly statements come back as one continuous file. Since each Intacct import covers a single account, batching by account rather than by month matches how the import actually works. The bulk bank statement converter page covers how batching and merging behave.

Checking the import before you reconcile

Two checks catch nearly everything. Compare the transaction count and the closing balance of each converted statement against the printed document, because a matching closing balance is strong evidence that the lines in between are right. Then, after the import, confirm the earliest and latest dates that arrived match the statement period, which is how a date order misread gives itself away before it reaches a reconciliation.

The date check is worth doing every time on this platform specifically, because the two import routes handle dates differently. The classic import wants MM/DD/YYYY, while the assistant asks you to select the correct date order on the review screen. Any statement dated before the thirteenth of a month can be read either way without looking wrong, so a quick comparison against the source document is the only reliable catch. If something does need untangling afterwards, imported transactions stay in Intacct even after reconciliation, and duplicates can be ignored rather than deleted.