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.

In practice, BMD's direct import path is for structured exports. PDF statements usually need conversion to CSV or Excel before import.

That is the key workflow decision for a successful BMD bank statement import. The real question is not whether BMD supports imports in theory. The real question is which path fits the file the bank or client actually sent you. A clean CAMT export and a scanned PDF may both contain the same transactions, but they do not belong in the same import workflow.

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.

For most teams, that one decision avoids more rework than any downstream cleanup step. A direct structured-file import is usually the fastest and safest option because the transaction data already exists in importable form. A PDF is different: it is designed for reading, not for bookkeeping import. If you push a PDF-based dataset into BMD without first turning it into a structured table, you usually create extra work in mapping, amount correction, and reconciliation.

This guide is about practical workflow choices inside BMD NTCS, not a generic product overview. The goal is to help you identify the right import path early so you can avoid manual re-entry, broken imports, and avoidable reconciliation delays.

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.

A quick decision rule helps here. Choose CAMT if your bank offers it and you want the most modern structured export. Choose MT940 if that is the bank's available statement standard and the file is clean. Choose Edifact if your banking or ERP environment already exchanges statement data that way. Choose CSV when no richer banking format is available but you can still control the file layout tightly enough for a predictable import. The worse the column discipline, the more CSV turns from a shortcut into a cleanup task.

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.

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.

How Austrian Client Handoffs Change the Best Workflow

The best way to import bank statements into BMD is often decided before you ever open BMD. In Austrian bookkeeping, the real constraint is usually the monthly handoff: what the client, bank portal, or internal finance team actually sends you. If that handoff is a structured export such as CAMT, MT940, Edifact, or a stable bank CSV, you can build a direct import routine. If the handoff is only a PDF attachment, a scanned statement, or a different export every month, the better workflow is to standardize the data first and only then move it into BMD.

That distinction matters more as firms digitize. According to Statistics Austria's 2025 SME digitalisation data, 73% of small and medium-sized enterprises in Austria had at least a basic level of digitalisation in 2025. For Austrian accountants, that does not automatically mean cleaner bookkeeping inputs. It often means more files arrive digitally but not in the same structure, so saved mappings break, sign logic changes, or statement periods overlap from one month to the next.

For a one-off import, you can be pragmatic. If a client sends a single CSV export or one PDF statement for cleanup, you may accept some manual preparation because the job is exceptional. For a recurring monthly workflow, that approach becomes expensive fast. Reconciliation slows down, posting dates get delayed, and each period starts with the same format check again. In recurring work, the goal should be to request the same export type and the same mapping standard every period whenever possible.

The practical split is clear. Business owners should send the cleanest export they can get from the bank, ideally the structured format already available in their banking portal rather than a forwarded PDF. Accountants and bookkeepers should define the handoff standard in advance, so the client knows exactly what "usable for BMD" means before next month's statement run.

A good Austrian handoff standard usually specifies:

• the preferred file type for that client or bank, such as CAMT, MT940, Edifact, or a specific CSV export
• the required fields, such as booking date, value date, amount, currency, counterparty, reference, and running balance
• how debit and credit signs should appear
• which decimal and delimiter conventions are expected in the 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 Austrian clients, do not treat "bank statement import" as one single process. Treat it as a client handoff policy. One client may reliably deliver CAMT every month. Another may only send Raiffeisen or Sparkasse PDFs by email. A third may export CSV, but with inconsistent column headers depending on who downloaded it. Once you standardize the incoming path per client, BMD imports stop being a monthly formatting surprise and start becoming a repeatable bookkeeping routine.

---

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: A CSV may look fine in one app but still break on import because the separator or character encoding does not match what BMD expects. Typical symptoms are all values landing in one column, umlauts displaying incorrectly, or reference fields being cut off. The fix is usually to re-export the CSV with the correct delimiter and encoding, not to keep patching columns by hand.

• Date parsing errors: If booking dates, value dates, or statement dates import incorrectly, check whether the file uses day-month-year, year-month-day, or locale-specific formats. Mixed date formats in one file are a red flag. Re-export the source if possible. If the source is a PDF conversion, reconvert it with explicit date normalization before trying BMD again.

• Decimal separator problems: Austrian workflows often run into commas versus dots. If amounts import as 1250 instead of 12,50, or 12.50 becomes text, the decimal logic is wrong before the file reaches BMD. Do not correct hundreds of rows manually. Re-export the CSV or rebuild the conversion so every amount follows one consistent numeric pattern.

• Sign inversion: Credits and debits are easy to flip, especially in CSV exports where one bank uses separate debit and credit columns and another uses a single signed amount column. If payments appear positive when they should reduce the balance, stop immediately. Check whether the source uses separate inflow and outflow fields, whether negative signs were stripped during Excel editing, and whether your mapping assumes the opposite convention.

• Partial statement files: A file that contains only page 1 of a PDF statement, drops later transaction pages, or excludes continuation lines will create missing movements and broken balance logic. If the closing balance does not reconcile to the imported transactions, assume the file is incomplete until proven otherwise. Get a complete export from the bank portal or reconvert the full PDF from the original source.

• Weak or inconsistent transaction descriptions: If booking text, payer/payee details, or references are missing, inconsistent, or split across columns, downstream matching in BMD becomes unreliable. This is common in client-supplied CSVs and PDF conversions. If the raw source does not preserve usable transaction text, forcing the import into BMD will not improve it. Ask for a better export, preferably CAMT, MT940, or a cleaner CSV, or reconvert the PDF with a layout that keeps 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.