How to Import Bank Statements into BMD (CAMT, MT940, CSV, PDF)

To import bank statements into BMD, start with the file type you actually have. In BMD NTCS, BMD Bankauszugsverbuchung can usually import structured bank statement files such as CAMT, MT940, Edifact, and many CSV exports directly. If the only source is a PDF bank statement, the practical route is to convert it into a clean CSV or spreadsheet first, then check field mapping, debit and credit signs, and saldo logic before you import.

Use this decision path first:

• You have a structured bank export such as CAMT, MT940, Edifact, or a bank CSV with consistent columns: use the direct import route in BMD Bankauszugsverbuchung.
• You only have a PDF statement or a messy export with merged cells, unclear columns, or inconsistent signs: use the conversion and cleanup route before import.
• You receive statements from the same client every month but the incoming files vary: standardize the handoff format first, then import the same way each cycle.

When CAMT, MT940, Edifact, or CSV Are the Best Route

The direct BMD route works best when your source file already contains structured transaction data, meaning each booking is already broken into usable fields such as date, amount, text, counterparty, and balance. In that situation, BMD Bankimport is usually faster and more reliable than any manual rebuild. If you already have a clean export from the bank or treasury system, do not create extra work by converting a PDF first.

For most teams, CAMT and MT940 are the strongest options when the bank can provide them. A BMD CAMT import is often the best fit because CAMT files are designed to carry structured account statement data in a consistent machine-readable layout. A BMD MT940 import is also a strong choice, especially when a bank still offers MT940 as its standard export. If you need a deeper format comparison, this guide to MT940 and CAMT.053 bank statement formats is useful background, but for day-to-day bookkeeping the practical point is simple: if the bank can export CAMT or MT940, start there before considering any workaround.

Edifact can also be the right path, but it is more situational. You are more likely to see it in corporate banking, EDI-heavy workflows, or finance environments where statement data is already exchanged between systems rather than downloaded manually by a bookkeeper. When Edifact is available in a format BMD accepts, it can reduce rekeying and preserve structure well. The tradeoff is availability: many smaller teams will see CAMT, MT940, or CSV more often than Edifact in real client handoffs.

CSV is the most flexible option, but it is also the format most likely to need cleanup before import. CSV works well for BMD Bankimport when the file is consistently prepared, especially in four areas:

• The column order stays the same from row to row and from file to file.
• Dates use one format throughout, such as DD.MM.YYYY or YYYY-MM-DD, without mixing styles.
• Debit and credit amounts use a consistent sign convention, so negatives are always negative and credits are not alternately shown with text labels or separate columns.
• Opening or running balances are handled consistently, because missing or irregular balance fields can create import and reconciliation problems later.

Set Up BMD Before You Import the First Statement

In BMD, the first statement import should be treated as a setup task, not a blind upload. Before you import a live month, make sure the file is tied to the correct Bankverbindung and the correct Bankauszugskreis. If either one is wrong, you can end up with failed mapping, incorrect transaction interpretation, or cleanup work after the data is already in your bookkeeping flow.

The Bankverbindung is the bank account record BMD uses as the base reference for the import. The Bankauszugskreis is the statement import profile built around that connection. In practice, that profile determines which file type you are bringing in, how BMD should read it, and which mapping logic applies to that account. That is why BMD Bankauszugskreis setup matters so much: it is the difference between a repeatable import workflow and a file that technically loads but produces unusable output.

Many teams set this up with a sample or dummy file before importing a full statement period. That test run lets you verify the field assignment, balance logic, separators, and signs without risking a whole month of transactions. For CAMT or MT940, the structure is usually tighter. For a BMD bank statement CSV import, the first test is even more important because CSV quality depends entirely on the bank export or the client-made file you received.

For CSV import, BMD needs enough structure to map each row reliably. At a minimum, check that the file contains:

• a booking date or value date
• a transaction description, payment reference, or other meaningful text field
• an amount field
• a clear debit/credit direction, or a sign convention that makes inflows and outflows unambiguous
• opening and closing balance fields, or a consistent running saldo column if your reconciliation process depends on balance checks

Before the first live import, verify the technical basics that usually cause avoidable problems:

• Date format consistency: one date pattern throughout the file, not mixed formats in different rows
• Decimal separators: commas and periods must match the way the export represents amounts
• Delimiters: confirm whether the file uses semicolons, commas, or tabs
• Column order: make sure the saved mapping still matches the actual export
• Text encoding: special characters, umlauts, and references should import cleanly
• Sign handling: negative amounts, positive amounts, or separate debit/credit columns must behave consistently

Do not assume a mixed client CSV layout is safe just because a previous file worked. Banks, portals, ERP exports, and manually adjusted spreadsheets often change header names, column order, delimiters, or sign logic without warning. Recheck each client-specific CSV before every import, especially if the statement came from a different user, a different bank account, or a different export path. That short preflight check is what keeps a CSV import from becoming a posting and reconciliation problem later.

For recurring Austrian clients, it pays to lock down the handoff format rather than treat each month as a surprise. According to Statistics Austria's 2025 SME digitalisation data, 73% of small and medium-sized enterprises had at least a basic level of digitalisation in 2025 — which usually means more files arrive digitally but not in the same structure. A good Austrian handoff standard specifies:

• the preferred file type for that client or bank (CAMT, MT940, Edifact, or a specific CSV export)
• the required fields (booking date, value date, amount, currency, counterparty, reference, running balance)
• how debit and credit signs should appear
• decimal and delimiter conventions for CSV
• whether statement periods must be split by month or account
• what to send if the bank only offers PDF for that account

If you manage multiple clients, treat bank statement import as a client handoff policy — standardize the incoming path per client and the BMD import stops being a monthly formatting surprise. If the same clients also send supplier invoices that need capture into BMD, the BMD invoice scanning workflow follows the same standardize-first principle.

What to Do When the Source File Is Only a PDF

If the only file you have is a PDF, treat it as a source document, not as the final import file. In most cases, PDF bank statements need to be converted into a clean structured CSV or spreadsheet first, because BMD works best when the transaction data is already normalized into consistent columns. If the bank can still provide CAMT, MT940, Edifact, or a bank-generated CSV, that remains the better route. The PDF workflow is the fallback for cases where the source is only a PDF, a scan, or an export that is too inconsistent to map reliably.

A workable PDF bank statement to CSV for BMD process has one job: preserve the fields BMD needs for booking and reconciliation. Your converted file should keep, at minimum:

• Transaction dates, and if relevant both booking date and value date
• Descriptions, references, and counterparty text
• Amounts, with decimals and separators standardized
• Debit or credit direction, so negative and positive logic does not get flipped
• Balances or running saldo logic, if your import or downstream reconciliation depends on opening, closing, or per-line balances

If any of those elements are lost during conversion, the file may still look tidy in Excel but fail when you try to reconcile it in BMD. That is why the real task is not just to convert PDF bank statements for BMD, but to convert them into a structure that still reflects the original statement logic.

A practical workflow looks like this:

1. Ask once for a structured export first: CAMT, MT940, Edifact, or a bank CSV.
2. If that is not available, extract the PDF statement into Excel or CSV.
3. Normalize the output so every transaction sits on one row with stable column names, consistent date formatting, and clear debit or credit handling.
4. Check totals, opening balance, closing balance, and line count against the original PDF before you import anything into BMD.

That fallback is not an edge case in Austria. Many accountants and bookkeepers receive downloaded PDFs, scans, or ad hoc exports from clients rather than a clean CAMT or MT940 file. In practice, the normalization step is often part of the bookkeeping workflow itself. If you want a deeper walkthrough on converting PDF bank statements into clean Excel or CSV files, use that process before you build the BMD import file.

If your team needs bank statement extraction software for that bridge step, Invoice Data Extraction can turn PDF or scanned bank statements into structured CSV, Excel, or JSON so you have cleaner columns to map into BMD.

Run Reconciliation Checks Before You Post the Imported Data

A successful import only tells you that BMD accepted the file structure. It does not confirm that the statement period is complete, that every amount has the right sign, or that the transactions are safe to post. That matters even more when you import bank transactions into BMD from a prepared CSV or data converted from PDF, because those workflows introduce extra mapping and normalization steps before the data ever reaches bookkeeping.

Treat BMD bank statement reconciliation as a control step before posting, matching, or automated account assignment. You want to confirm that the imported lines represent the real bank statement, in the right order, for the full period.

Run these checks before you rely on automated posting logic or reconciliation routines:

• Check the full statement period. Confirm the import starts with the correct opening date and ends with the correct closing date for the statement or period you intended to book. Missing the first or last days of a statement creates false differences later, even if the middle of the file looks fine.
• Verify opening and closing saldo. Compare the imported opening balance and ending balance against the bank statement itself. If those numbers do not tie out, stop there. A balance mismatch usually means lines are missing, duplicated, or assigned the wrong sign.
• Scan for duplicate lines. Look for repeated bookings with the same booking date, amount, counterparty, and reference. Duplicates often appear when a client sends overlapping exports, or when a CSV is rebuilt from a prior import and imported again.
• Check for missing charges and bank fees. Small fee lines are easy to lose in CSV preparation and PDF conversion, especially when the source layout is inconsistent. If fees are missing, your posting totals may still look close while the bank balance no longer reconciles cleanly.
• Confirm debit and credit signs. Incoming receipts, outgoing payments, refunds, chargebacks, and bank fees must all have the correct positive or negative direction. Sign errors are one of the fastest ways to break matching and create misleading open items.
• Review transaction references and purpose text. Imported rows should carry usable references such as payment purpose, counterparty name, mandate text, invoice reference, or bank booking text. If those fields are blank or truncated, automated matching becomes much weaker and manual rework increases.

This review is especially important when the source was not a pristine CAMT or MT940 export. With CSV preparation, columns may be mapped correctly but still contain wrong date formats, split amounts, or incomplete reference fields. With PDF conversion, the data may look structured while still missing continued lines, folded text, or charges shown in separate statement sections. A file can be technically valid for import and still be unreliable for posting.

As a practical rule, do not move from import to posting until the imported totals, balances, and booking lines agree with the source statement. If you want a broader control list for this review stage, use these bank statement reconciliation checks after import as part of your normal bank reconciliation process.

Common BMD Bank Import Errors and How to Troubleshoot Them

When a BMD Bankimport fails, or imports with wrong values, troubleshoot in this order:

1. Confirm the real source format first. Check whether you actually have CAMT, MT940, Edifact, a bank-exported CSV, or a converted file from PDF. Do not treat a manually edited spreadsheet as if it were a native bank export.
2. Inspect the file before importing. Look at the columns, date format, decimal separator, sign logic, and whether opening and closing balances match the statement period you expect.
3. Test with a small sample. Import a short date range or a few rows first, especially after changing mappings or reconverting a file.
4. Run the full import only after the sample is clean. If the sample shows wrong dates, broken amounts, or missing descriptions, the full import will usually multiply the problem.

The most common failure modes are straightforward once you isolate whether the issue comes from the source file, the mapping, or the statement period.

• Delimiter or encoding mismatch: Values all landing in one column or umlauts displaying as garbage means the separator or encoding is wrong. Re-export the CSV with the correct delimiter and UTF-8 encoding instead of patching columns by hand.

• Date parsing errors: If booking or value dates import wrong, the file is using a format BMD is not expecting, or it mixes formats mid-file. Re-export the source, or if it came from a PDF conversion, reconvert with explicit date normalization.

• Decimal separator problems: Commas versus dots is the Austrian classic — amounts like 1250 instead of 12,50 mean the decimal convention is inconsistent. Fix it at export or conversion time, not row by row.

• Sign inversion: Credits and debits flip when one bank uses separate debit/credit columns and the next uses one signed amount. If payments appear positive when they should reduce the balance, stop and check the source convention and mapping.

• Partial statement files: If the closing balance does not reconcile, assume the file is incomplete (page 1 only, missing continuation lines, or a dropped section). Get a full export from the bank portal or reconvert the entire PDF.

• Weak transaction descriptions: Missing or truncated booking text, references, or counterparty fields make downstream matching unreliable. Ask for a better export (CAMT, MT940, or a cleaner CSV), or reconvert the PDF with reference data in dedicated fields.

A practical rule helps: if the file structure is wrong, re-export or reconvert; if the structure is right but BMD reads it incorrectly, review mapping and import settings. Trying to force a broken layout through BMD usually costs more time than starting again with a clean source and a small test import.