Skip to main content
Docs / Core

Import a bank statement

Upload an OFX, CAMT.053, MT940, or BAI2 statement, auto-match the lines to open invoices and payments, review what is left, and re-import safely without doubling up.

You can hand ERPClaw a bank statement file and it matches the lines to invoices and payments you already have on the books. Say it the way you would out loud: “import my January bank statement and match it to open invoices.”

The formats you can upload

ERPClaw reads the four statement formats banks actually export:

  • OFX (Open Financial Exchange), the common download from US and Canadian banks
  • CAMT.053, the ISO 20022 statement most European banks issue
  • MT940, the long-standing SWIFT statement format
  • BAI2, the cash-management format from US corporate banking

Pick whichever your bank gives you. There is nothing extra to install for any of them, and ERPClaw detects the format on its own unless you name it.

Step 1, import the file

integration-import-bank-statement --file ~/statements/checking-january.ofx --bank-account-name "Checking"

Point it at the file and name the bank account the statement belongs to. The format is detected automatically; pass --format (ofx, camt053, mt940, or bai2) only if you want to be explicit.

The bank account is resolved by name within your company. If you name an account that does not exist, ERPClaw stops and tells you, rather than guessing a different account. It never quietly imports a statement into the wrong place. Each transaction on the statement becomes a line on the imported record, ready to match.

Step 2, auto-match to open invoices and payments

integration-auto-match-bank-statement --statement-id <id>

The matching engine runs your rules over the imported lines and links each one it can place to an open invoice or payment. A deposit that clears an outstanding customer invoice gets paired with that invoice; a withdrawal that settles a bill gets paired with that payment. The lines it is confident about are matched in one pass.

Teach it your patterns with match rules

You can give the engine standing rules so recurring lines match themselves:

integration-add-bank-match-rule --name "Stripe payouts" --match-field description --match-operator contains --match-value "STRIPE" --target-action map_to_account

A rule looks at one field on the line (description, counterparty_name, reference, or amount), tests it (equals, contains, regex, or amount_range written as min:max), and on a hit routes the line to an account, a vendor, or a customer (map_to_account, map_to_vendor, map_to_customer), or tells the engine to leave it alone (ignore). Give rules a --priority to control which one wins when more than one could apply. List what you have with integration-list-bank-match-rules.

Step 3, review the unmatched lines

The engine leaves anything it cannot place with confidence for you to look at:

integration-unmatched-bank-lines --statement-id <id>

Match those by hand:

integration-manual-match-bank-line --line-id <id> --target-action map_to_vendor --target-id <vendor-id>

Changed your mind about a match? Clear it and the line goes back into the unmatched pile:

integration-clear-bank-line-match --line-id <id>

Re-import safety, no duplicates

Re-importing the same file is safe. Every line carries its own identifier from the bank, and any line already on the books is skipped on the way in. So if a download was interrupted, or you are not sure whether January already went through, you can run the import again without doubling up the statement.

Reconcile and close out

When the lines are matched, check where the account stands:

integration-bank-reconciliation-summary --bank-account-name "Checking"

Add --as-of <date> to see the picture at a cutoff. You can also integration-list-bank-statements to see what has been imported, integration-get-bank-statement --statement-id <id> to open one, and integration-archive-bank-statement --statement-id <id> to file away a statement you are done with.

What is next

See Core features