Разбиране на форматите на банкови извлечения: Техническото ръководство

PDF на банково извлечение изглежда просто: дати, описания, суми, салда в подредени колони. Но зад този вид се крие формат на документ (PDF), който никога не е бил проектиран да съхранява структурирани данни — и процес на преобразуване, който изисква разбиране както на входния формат, така и на многото налични изходни формати.

Това ръководство обхваща 12-те секции, които се появяват във всяко банково извлечение (независимо от банката), техническата реалност на PDF файловете на банкови извлечения, вариациите в оформлението при различните банки, всеки изходен формат, който ще срещнете (Excel, CSV, QBO, OFX, QFX, QIF, JSON), разликите в международното форматиране и индустриалните стандарти, които управляват обмена на финансови данни.

Анатомия на банково извлечение

Всяко банково извлечение — Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, което и да е — е изградено от едни и същи 12 секции. Етикетите се променят („Субтракции“ срещу „Тегления“), подредбата на колоните варира, но основната структура е последователна. След като можете да идентифицирате тези секции, всяко извлечение изглежда познато.

Искате ли да използвате тази инфографика в блога си? Копирайте този код за вграждане:

За задълбочени анализи за конкретни банки, покриващи точно как всяка голяма банка подрежда тези 12 секции, вижте:

• Обяснение на банково извлечение от Chase
• Обяснение на банково извлечение от Bank of America
• Обяснение на банково извлечение от Wells Fargo
• Обяснение на банково извлечение от Citi
• Обяснение на банково извлечение от Capital One

Защо PDF не е формат за данни

PDF означава Portable Document Format (Преносим формат на документ), стандартизиран като ISO 32000 (версия 2.0 стана ISO 32000-2:2020). Той е проектиран с една цел: документите да изглеждат идентично на всеки екран и принтер. Това е чудесно за визуална точност — и ужасно за извличане на данни.

Какво всъщност има вътре в PDF на банково извлечение

Вътре във всяка страница на PDF има поток от съдържание — последователност от оператори за рисуване, написани на език, подобен на PostScript. Текстът се изобразява с помощта на специфични оператори:

• BT / ET — Начало на текст / Край на текст: граници на текстов обект
• Tf — Задаване на шрифт и размер
• Td / Tm — Преместване на позицията на текста или задаване на пълната матрица за трансформация на текста
• Tj — Показване на текстов низ
• TJ — Показване на текст с индивидуално позициониране на глифовете (корекции на кернинга)

Ключовото прозрение: в спецификацията на PDF няма концепция за „таблица“, „ред“ или „колона“. Това, което изглежда като добре форматирана таблица с трансакции, всъщност е десетки текстови фрагменти, поставени на специфични x,y координати на страницата. Инструментът за извличане трябва:

1. Да анализира операторите на потока от съдържание
2. Да разреши кодировките на шрифтовете, за да съпостави индексите на глифовете с Unicode символи
3. Да използва текстовата матрица (Tm/Td), за да определи x,y позицията на всеки символ
4. Да реконструира думи, редове и колони от тези координати

Колона, която изглежда перфектно подравнена, може да е на x=72.0 в един ред и x=72.5 в следващия. Алгоритъмът за извличане трябва да дефинира границите на колоните с толерантност към тези вариации под пиксела.

Тагнати срещу нетагнати PDF файлове

Тагнатите PDF файлове включват скрито дърво на логическата структура (подобно на HTML тагове), което маркира съдържанието като заглавия, параграфи, таблици, редове на таблици и клетки на таблици. Това прави извличането значително по-лесно.

Нетагнатите PDF файлове нямат метаданни за структура — инструментът за извличане получава само сурови данни за позициониране и трябва да изведе всичко.

Повечето PDF извлечения, генерирани от банки, са нетагнати. Банките генерират извлечения чрез системи за пакетна обработка (Oracle BI Publisher, SAP Crystal Reports или персонализирани конвейери за печат към PDF). Регулациите за достъпност (ADA/WCAG) тласкат банките към тагнати PDF файлове, но приемането е бавно. Стандартните изтегляния от повечето големи банки остават нетагнати.

Вариации в оформлението на банкови извлечения

Няма индустриален стандарт за това как банките форматират своите PDF извлечения. Едни и същи пет части информация — дата, описание, дебит, кредит, салдо — са подредени различно от всяка банка.

Единична колона за суми (с знак)

Дата Описание Сума Салдо
01/15/26 ДИРЕКТЕН ДЕПОЗИТ ЗАПЛАТА  +3,500.00 5,200.00
01/16/26 ПОКУПКА НА ПОС ХРАНИТЕЛНИ  -87.50 5,112.50

Дебитите са отрицателни, кредитите са положителни (или обратното). Често срещано при по-малки банки, кредитни съюзи и дигитални банки. По-лесно за анализ, защото има една колона за суми за извличане.

Отделни колони за дебит/кредит

Дата Описание Тегления  Депозити Салдо
01/15/26 ДИРЕКТЕН ДЕПОЗИТ ЗАПЛАТА 3,500.00 5,200.00
01/16/26 ПОКУПКА НА ПОС ХРАНИТЕЛНИ 87.50 5,112.50

Използва се от Chase, Bank of America и много традиционни банки. Инструментът за извличане трябва да идентифицира коя колона съдържа сумата и да определи знака съответно.

Групирани по тип трансакция

Бизнес и корпоративни сметки често групират трансакции:

ДЕПОЗИТИ И ДРУГИ КРЕДИТИ 01/15  Телеграфен превод Вх.  РЕФ#12345 10,000.00 01/18  Депозит с чек #4567 2,500.00 Общо депозити 12,500.00
 
ЧЕКОВЕ ПЛАТЕНИ 01/16  Чек #1234 850.00 01/17  Чек #1235 1,200.00 Общо платени чекове 2,050.00
 
ЕЛЕКТРОННИ ТРАНСАКЦИИ 01/19  ACH ПЛАЩАНЕ - Vendor Corp 3,200.00 01/20  Онлайн превод към Спестовна сметка 1,000.00 Общо електронни 4,200.00

Заглавията на секциите определят дали трансакциите са дебити или кредити. Обобщаващите редове („Общо депозити“) трябва да бъдат идентифицирани и изключени от данните за трансакциите.

Специфични характеристики на банките

• Chase — Отделни колони за дебит/кредит; групира по „ДЕПОЗИТИ И ДОБАВКИ“ и „ЕЛЕКТРОННИ ПЛАЩАНИЯ“ и „ТАКСИ“; често срещани описания на няколко реда за детайли за търговец
• Bank of America — Отделни колони за тегления/депозити; включва секция „Дневни салда“ в края; обширно заглавие с номер на сметка, период на извлечението, маршрутен номер
• Wells Fargo — Отделни колони; включва секция „ОБОБЩЕНИЕ НА ДНЕВНИТЕ САЛДА“; нарича своя CSV изтегляне „Разделено със запетая“
• Capital One — Изчистено оформление с една сума за потребителски карти; минимална информация в заглавието
• Citi — Често включва подробности за международни трансакции с оригинални валутни суми и обменни курсове на отделни редове

Вариации в подредбата на колоните

Освен въпроса за дебит/кредит, подредбата на колоните не е стандартизирана:

• Ред на колоните: Дата-Описание-Сума-Салдо срещу Дата-Сума-Описание-Салдо
• Номер на чек: Присъства при бизнес сметки, отсъства при лични
• Референтен номер: Често срещан при бизнес извлечения, рядко при лични
• Текущо салдо: На трансакция (най-често срещано) срещу дневни подсуми или изобщо отсъстващо

Дигитални срещу сканирани PDF файлове

Единственият най-важен фактор, влияещ върху точността на преобразуването, е дали вашият PDF е дигитален или сканиран.

Дигитални (оригинални) PDF файлове

Създадени програмно от системата на вашата банка, когато изтегляте извлечение. Текстът се съхранява като оператори на потока от съдържание с кодировки на шрифтове.

• Точност: 99%+ за извличане на текст — няма грешки при разпознаване
• Скорост: Милисекунди на страница
• Поверителност: Може да се обработва изцяло във вашия браузър — файлът никога не напуска вашето устройство
• Размер на файла: Обикновено 50KB–500KB на страница
• Как да идентифицирате: Можете да избирате и маркирате отделни думи

Сканирани PDF файлове

Изображения на хартиени извлечения — създадени чрез сканиране или фотографиране на физически документ. Съдържанието се съхранява като растрирани изображения (JPEG, JPEG2000, CCITT или компресирани с Flate).

• Точност: 95–99% с професионален OCR; 65–70% с общ OCR
• Скорост: Секунди на страница (изисква обработка на изображения)
• Поверителност: Обикновено изисква сървърна обработка (файлът трябва да бъде качен за OCR)
• Размер на файла: 200KB–2MB+ на страница
• Как да идентифицирате: Не можете да избирате текст; увеличаване до 400% показва пикселизация

Защо точността на сканирането е по-важна за финансови данни

Скорост на точност на символите от 97% звучи отлично, докато не я приложите към финансови данни. На извлечение с 1000 символа на суми, това са 30 неправилно прочетени символа. Една неправилно прочетена цифра променя сумата на трансакция: „1234,56 лв.“ става „1234,86 лв.“ или „7234,56 лв.“. Разширеното OCR постига почти 99% точност, но оставащите грешки непропорционално засягат символи, които изглеждат сходни: 0/O, 1/l/I, 5/S, 8/B, 6/G и критично, запетая/точка. Винаги предпочитайте дигитални изтегляния. Изтегляйте извлечения от уебсайта на вашата банка, вместо да сканирате хартия. Това елиминира грешките от OCR напълно.

Изходни формати: Задълбочен анализ

Когато конвертирате банково извлечение, вие избирате изходен формат. Всеки формат има различни силни страни, ограничения и идеални случаи на употреба.

Excel (.xlsx)

Стандарт: Office Open XML (OOXML), стандартизиран като ECMA-376 и ISO/IEC 29500.

Какво е това: .xlsx файл всъщност е ZIP архив, съдържащ XML файлове — структура на работната книга, данни за клетки, стилове и споделени низове. Ето защо той може да съхранява типове данни (дати като дати, числа като числа), форматиране, формули и множество листове.

Защо е популярен за банкови извлечения:

• Датите остават дати (сортируеми, филтрируеми)
• Числата остават числа (сумираеми, форматируеми)
• Формули за съгласуване (SUM, VLOOKUP)
• Пивотни таблици за категоризиране на разходите
• Условно форматиране за подчертаване на несъответствия
• Споделяне с клиенти, които се нуждаят от четим електронна таблица

Ограничения:

• Максимум 1 048 576 реда (рядко релевантно за банкови извлечения)
• Не се импортира директно в повечето счетоводни софтуери (използвайте QBO/OFX вместо това)
• Изисква Excel, Google Sheets или LibreOffice Calc за отваряне

Най-добър за: Ръчен преглед, персонализиран анализ, съгласуване, архивиране, отчитане пред клиенти.

CSV (Comma-Separated Values - Стойности, разделени със запетая)

Стандарт: RFC 4180 (2005) — „Общ формат и MIME тип за стойности, разделени със запетая“.

Основни правила:

• Записите се разделят с CRLF (връщане на каретка + нов ред)
• Полетата се разделят със запетаи
• Полета, съдържащи запетаи, кавички или нови редове, трябва да бъдат оградени в двойни кавички
• Двойните кавички в полетата се избягват чрез удвояването им

Вариации на разделителя в употреба:

• Запетая (,) — Стандарт, използван в САЩ/Великобритания
• Точка и запетая (;) — Използва се в страни, където запетаята е десетичен разделител (Франция, Германия, Италия, Испания, Бразилия)
• Табулация (\t) — TSV формат, избягва конфликти на разделители

Проблеми с кодирането:

• UTF-8 се препоръчва за оперативна съвместимост
• UTF-8 BOM (Byte Order Mark - Маркер за ред на байтовете): Не се изисква от стандарта, но Excel под Windows го изисква, за да показва правилно не-ASCII символи (букви с ударения, символи за валута). Без BOM, Excel може да интерпретира UTF-8 като Windows-1252, повреждайки символите.
• Excel използва точки и запетаи вместо запетаи като разделители на полета в европейски локали

Ограничения:

• Няма типове данни — всичко е текст (числа с водещи нули се повреждат, дълги номера на сметки стават научна нотация)
• Няма поддръжка за множество листове
• Няма форматиране или формули
• Няма метаданни (няма информация за сметката, няма идентификатори за откриване на дубликати)

Най-добър за: Максимална съвместимост — почти всяка счетоводна програма, база данни и електронна таблица може да импортира CSV. Универсален резервен вариант, когато QBO/OFX не е наличен.

QBO (QuickBooks Web Connect)

Какво е това: Формат за импортиране за QuickBooks (както Desktop, така и Online). QBO файловете са базирани на спецификацията OFX с разширения, специфични за QuickBooks.

Важно уточнение: ".QBO" НЕ означава „QuickBooks Online“ — той означава формат QuickBooks Web Connect и работи както с QuickBooks Desktop, така и с QuickBooks Online.

Задължителни полета на трансакция:

• TRNTYPE — Тип на трансакцията (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED — Дата във формат YYYYMMDD
• TRNAMT — Сума (отрицателна за дебити)
• FITID — Идентификатор на трансакцията от финансовата институция
• NAME — Получател/описание

Защо FITID е важен: QuickBooks следи всеки FITID, който някога е бил импортиран за всяка сметка. Ако трансакция със същия FITID бъде импортирана отново, QuickBooks я пропуска мълчаливо — предотвратявайки дублиращи се записи, когато потребителите повторно импортират припокриващи се периоди на извлечения. Това автоматично откриване на дубликати е най-голямото предимство на QBO пред CSV.

Допълнителни данни: QBO също носи идентификатор на сметката, идентификатор на банката (маршрутен номер), валута, номер на чек, бележка и крайно салдо — най-богатият набор от данни от всеки формат за импортиране за QuickBooks.

Най-добър за: Потребители на QuickBooks (Desktop и Online). Осигурява най-богатото изживяване при импортиране с автоматично откриване на дубликати и класификация на типовете трансакции.

OFX (Open Financial Exchange - Отворен финансов обмен)

История: Създаден от Microsoft, Intuit и CheckFree. Версия 1.0 е пусната през февруари 1997 г.

Еволюция на версиите:

• OFX 1.0–1.6 (1997–1999): Синтаксис, базиран на SGML (не се изискват затварящи тагове)
• OFX 2.0+ (2000–настояще): Базиран на XML (правилни затварящи тагове, добре оформен XML)

Много банки все още произвеждат OFX 1.x (SGML) за максимална съвместимост.

Текущо управление: През 2019 г. консорциумът OFX се сля с консорциума Financial Data Exchange (FDX), който сега управлява спецификацията. FDX има над 200 членуващи организации и 76 милиона потребителски сметки.

Защо OFX е универсалният стандарт: OFX е същият формат, използван, когато свързвате банковата си сметка директно към счетоводен софтуер чрез банкови връзки — същият формат работи и за импортиране на файлове.

Най-добър за потребители на Xero: Xero автоматично импортира OFX файлове, без да изисква ръчно съпоставяне на колони. Качете файла и трансакциите се появяват незабавно с правилни дати, суми и описания. Работи и с Wave, Sage, FreshBooks и повечето счетоводни софтуери.

QFX (Quicken Financial Exchange - Финансов обмен на Quicken)

Какво е това: Собствен вариант на OFX от Intuit, използван изключително с Quicken. QFX файлът е стандартен OFX файл с допълнителни собствени полета.

Ключово собствено поле: INTU.BID — Идентификатор на банката на Quicken. Този числов идентификатор се съпоставя с банка в базата данни на Quicken. Без него Quicken отказва да импортира файла.

Разлики от стандартния OFX:

• Изисква INTU.BID в заглавието
• Може да включва други полета с префикс INTU.*
• Финансовите институции плащат лицензионна такса на Intuit, за да предоставят QFX изтегляне
• Quicken няма да импортира стандартни OFX файлове без полето INTU.BID

Най-добър за: Потребители на софтуер за лични финанси Quicken. Задължителен формат — няма алтернатива, която да работи.

QIF (Quicken Interchange Format - Формат за обмен на Quicken)

Какво е това: Наследен формат с обикновен текст, първоначално разработен от Intuit за Quicken. Двойки ключ-стойност, по една на ред, с едноезични тагове: D за дата, T за сума, P за получател, L за категория, M за бележка, N за номер на чек, ^ за край на записа.

Защо беше заменен: QIF няма механизъм за откриване на дубликати (няма еквивалент на FITID), няма полета за идентификация на сметката, няма информация за маршрутизация на банката, няма данни за салдо и непоследователно форматиране на датите в различните имплементации.

Все още релевантен: Някои счетоводни софтуери (Xero, Sage, GnuCash) все още приемат QIF импортиране. Полезен за миграция на наследени системи.

JSON (JavaScript Object Notation)

Текущ статус: JSON все още не е стандарт за файлове с банкови извлечения, но се използва все по-често в:

• API за отворено банкиране (UK Open Banking Standard, PSD2 Berlin Group)
• FDX API (Financial Data Exchange — наследник на OFX, 200+ членуващи организации)
• Plaid, Yodlee, MX и други API на агрегатори на данни
• Работни процеси за разработчици и автоматизация

Нарастващо приемане: Регулациите за отворено банкиране (PSD2 в Европа, Раздел 1033 от CFPB в САЩ) ускоряват приемането на JSON API. FDX API използва JSON/REST с OAuth 2.0, представлявайки бъдещата посока на обмена на финансови данни.

Най-добър за: Разработчици, създаващи автоматизирани работни процеси, финтех интеграции, персонализирани табла за управление и интеграции с API за отворено банкиране.

Сравнение на форматите накратко

Съвместимост със счетоводен софтуер

Кой формат приема вашият счетоводен софтуер?

Общо правило: Използвайте QBO за QuickBooks, QFX за Quicken, OFX за всичко останало и CSV като универсален резервен вариант.

Международни разлики във форматирането

Ако работите с международни банкови извлечения, ще срещнете разлики във форматирането, които затрудняват повечето инструменти за преобразуване.

Формати на дати

Проблемът с двусмислието: „03/04/2026“ е 4 март в САЩ, но 3 април в Европа. Когато всички дати в извлечението имат стойности на деня 12 или по-малко, няма алгоритмичен начин да се определи правилният формат, без да се знае страната на произход. Инструментите за преобразуване трябва да сканират всички дати в извлечението, търсейки стойности, по-големи от 12, за да определят формата.

Формати на числа

„10.000,45“ от европейска банка означава десет хиляди и четиридесет и пет цента — не десет точка нула нула нула четири пет. Грешка тук води до грешки от порядъка на 10 000 пъти.

Поставяне на символа за валута

• САЩ/Великобритания: Символ преди сумата: $1,234.56 / £1,234.56
• Франция, Германия, Испания: Символ след сумата: 1.234,56 €
• Ирландия, Нидерландия: Символ преди: €1,234.56
• Япония: Символ преди: ¥123,456

Кодировки на символи

• UTF-8 — Универсален стандарт, поддържа всички азбуки
• GBK/GB2312 — Опростен китайски (използван от китайски банки)
• Shift_JIS — Японски (използван от японски банки)
• Big5 — Традиционен китайски (Тайван, Хонконг)
• EUC-KR — Корейски
• ISO 8859-1 — Западно европейски
• Windows-1252 — Западно европейски (наследен)
• Windows-1256 — Арабски

Отварянето на китайско или японско банково извлечение на американска система без правилно разпознаване на кодировката води до развалени символи. PDFSub обработва 130+ езика с автоматично разпознаване на формати на дати, формати на числа и кодировки на символи — включително арабски и иврит от дясно наляво, CJK символи и всички европейски набори от символи.

Чести елементи на банкови извлечения

Дата на трансакцията срещу дата на осчетоводяване срещу дата на стойностност

Банковите извлечения могат да включват множество дати за една трансакция:

• Дата на трансакцията — кога действително е извършено покупката или преводът
• Дата на осчетоводяване — кога банката я е обработила и записала (обикновено 1–3 работни дни по-късно за покупки с кредитна карта)
• Дата на стойностност — кога средствата действително са станали достъпни (засяга изчисляването на лихви, често срещано в международното банкиране)

Повечето потребителски извлечения показват само датата на осчетоводяване. Бизнес извлеченията често включват както дата на трансакцията, така и дата на осчетоводяване.

Представяне на дебит/кредит

Банките представят дебити и кредити по различен начин:

• Суми със знак: -87.50 за дебити, +3,500.00 за кредити
• Отделни колони: „Тегления“ и „Депозити“
• Съкращения: „DR“ за дебит, „CR“ за кредит (често срещано във Великобритания/Общността)
• Скоби: (87.50) за дебити (счетоводен конвенция)

Текущо салдо

• Салдо на трансакция — актуализирано след всяка трансакция (най-често срещано в американски потребителски извлечения)
• Само дневно салдо — салдо, показано в края на всеки ден (често срещано в бизнес извлечения)
• Без текущо салдо — само начални и крайни салда (някои международни извлечения)

Текущите салда са ценни за валидация: можете да проверите дали всяка трансакция правилно премества салдото от един ред към следващия.

Стандартна информация в заглавието

Повечето банкови извлечения включват: име на притежателя на сметката, номер на сметката (често частично маскиран), период на извлечението, начално и крайно салдо, общо депозити и тегления, и маршрутен код/сортировъчен код/SWIFT BIC на банката.

Защита с парола

Как банките криптират PDF файлове

Банките обикновено използват AES-128 или AES-256 криптиране. Съществуват два режима на защита:

• Потребителска парола (парола за отваряне): Изисква се за отваряне на файла
• Парола на собственика (парола за разрешения): PDF се отваря, но редактирането/копирането може да бъде ограничено

Чести модели на пароли

Други често срещани модели включват последните 4 цифри на номера на сметката, клиентски идентификатор или номер на член. Банките обикновено комуникират модела на паролата, когато за първи път активирате електронни извлечения.

Предизвикателства при многостранични извлечения

Дългите извлечения (бизнес сметки със стотици трансакции) създават няколко предизвикателства при извличането:

Разделени трансакции

Описанието на трансакция може да започне в долната част на една страница и да продължи в горната част на следващата. Конверторът трябва да открие продължаващи редове и да ги обедини в една трансакция.

Повтарящи се заглавия и долни колонтитули

Повечето банки повтарят заглавията на колоните на всяка страница, плюс номера на страници, правни откази от отговорност и маркетингов текст. Те трябва да бъдат идентифицирани и изключени от данните за трансакциите.

Продължаващи редове

Много трансакции имат описания на няколко реда:

01/15  ACH ЕЛЕКТРОНЕН ДЕБИТ VENDOR CORP $3,200.00  $2,000.00 РЕФ#123456789 ФАКТУРА 2026-001 VENDOR CORP СМЕТКИ ЗА ПЛАЩАНЕ

Редове 2 и 3 са продължаващи редове, принадлежащи към трансакцията на ред 1. Те обикновено нямат дата и сума, появяват се с отстъп на същия x-координат като колоната за описание.

Пренасяне на салдо

Някои банки включват редове „Салдо за пренасяне“ или „Салдо, пренесено от предишен период“ в горната част на продължаващите страници. Те са информативни, а не трансакции, и трябва да бъдат изключени от извлечените данни.

Чести съкращения на трансакции

Банковите извлечения използват съкращения, които варират между институциите:

Индустриални стандарти, които трябва да знаете

Тези формати се използват в корпоративното банкиране и управлението на паричните средства. Рядко ще ги срещнете директно, но разбирането им обяснява защо банковите извлечения работят по този начин.

BAI2 (Bank Administration Institute)

Използва се за автоматизирано управление на паричните средства и банково съгласуване в ERP системи (SAP, Oracle). ASCII формат с фиксирана ширина с кодове за типове трансакции (напр. 165 = предварително одобрен ACH кредит, 455 = ACH дебит, 495 = телеграфен превод навън). Първоначално пуснат през 1987 г., сега се поддържа от ASC X9.

SWIFT MT940 / MT940

Крайни дневни (MT940) и вътрешнодневни (MT942) банкови извлечения, използвани от банки по света за корпоративни клиенти и касови отдели. SWIFT обработва приблизително 45 милиона съобщения на ден. Формат, базиран на тагове, с идентификатори на полета, разделени с двоеточие.

ISO 20022 (camt.053)

Модерният XML-базиран заместител на MT940. Част от универсалния стандарт за финансови съобщения ISO 20022. По-богати данни от MT940, без ограничения за дължината на полетата, машинно разбираем XML с XSD валидация. SWIFT мигрира от MT съобщения към ISO 20022. SEPA (Единна зона за плащания в евро) задължава camt формат за европейски плащания.

NACHA ACH

Файловият формат за трансакции през Automated Clearing House в САЩ. ASCII с фиксирана ширина, точно 94 знака на ред. ACH обработва приблизително 30 милиарда трансакции годишно в САЩ. Когато банковото ви извлечение показва „ACH CREDIT“ или „ACH DEBIT“, основната трансакция е била предадена във формат NACHA между банките.

Избор на правилния формат за вашия работен процес

Ръководство за вземане на решения

Използвайте QBO, ако: Използвате QuickBooks (Desktop или Online). Получавате класификация на типовете трансакции, откриване на дубликати чрез FITID и най-богатите метаданни за импортиране.

Използвайте OFX, ако: Използвате Xero, Sage, Wave или друг софтуер, съвместим с OFX. Xero автоматично съпоставя полетата без ръчна конфигурация на колони.

Използвайте QFX, ако: Използвате Quicken. Това е единственият формат, който Quicken приема.

Използвайте Excel, ако: Трябва да прегледате, анализирате или манипулирате данни преди импортиране. Създайте пивотни таблици, изпълнете формули или подгответе отчети.

Използвайте CSV, ако: Вашият софтуер не е изброен по-горе или се нуждаете от максимална съвместимост между системите. Бъдете готови да съпоставяте колони ръчно.

Използвайте JSON, ако: Създавате автоматизирани работни процеси, API интеграции или системи за персонализирано отчитане.

Професионални съвети

• Винаги използвайте QBO/OFX пред CSV, когато вашият софтуер го поддържа — само откриването на дубликати спестява часове почистване
• Запазете оригиналния PDF заедно с конвертирания файл — това е вашата одитна пътека и изходен документ
• Проверявайте след всяко импортиране — правете выборочни проверки на начални/крайни салда и няколко случайни трансакции
• Съпоставяйте формата със софтуера — използването на родния формат за вашата счетоводна платформа избягва ръчното съпоставяне на колони и активира автоматични функции

Опитайте безплатно

Готови ли сте да конвертирате първото си извлечение? Качете PDF сега — PDFSub конвертира в Excel, CSV, QBO, OFX, QFX и JSON. Дигиталните извлечения се обработват изцяло във вашия браузър за максимална поверителност. Започнете 7-дневен безплатен пробен период с пълен достъп до всички формати.