Извличане на данни от фактури в Excel: ръководство за България

Извличане на данни от фактури в Excel означава превръщане на PDF, снимки и сканирани фактури в структурирана таблица с номер на фактура, дата, доставчик, ЕИК, ИН по ДДС, данъчна основа, ДДС, обща сума, валута и редове по артикули или услуги — така че счетоводител или служител от АП да може да прегледа, импортира или осчетоводи данните, без да набира нищо ръчно.

Полезната таблица не се ражда от инструмента, а от няколко решения, които взимате преди да отворите инструмента: кои са точните колони, какъв е форматът на датите, как се отразяват кредитните известия в същия лист и дали един ред в Excel означава един документ или един артикул от фактурата. Изборът на тези параметри определя дали изходът ще се внесе чисто в дневник покупки или ще ви накара да преработвате партидата след факта.

В България голяма част от входящите фактури още пристигат като PDF от имейл, снимки от телефон или сканирани документи от куриерска поща, а не като структурирани машинно-четими файлове, които счетоводната система може да обработи направо. Това не е субективно усещане. Националният статистически институт поддържа отделен показател за дела на предприятията, които изпращат електронни фактури, подходящи за автоматизирана обработка — официалния показател на НСИ за електронните фактури, подходящи за автоматизирана обработка. Фактът, че НСИ изобщо измерва това отделно, показва, че структурираното машинно-четимо фактуриране все още е измерима, обособена част от документооборота в страната, а не базовият стандарт за входящи фактури. Работният процес на превръщане на PDF и сканове в Excel остава реална и текуща задача за повечето български бизнеси.

---

Колоните, които всъщност искате накрая: схема за български фактури

За български контекст наборът от колони, който държи Excel изхода полезен в дневник покупки, в АП преглед и в счетоводен импорт, изглежда така:

• Тип документ — Фактура, Кредитно известие или Дебитно известие. Това е първата колона, защото определя как се четат всички следващи стойности.
• Номер на фактура — оригиналният номер на документа от доставчика. При кредитни и дебитни известия този номер идва от самото известие, не от фактурата, която то коригира (тази връзка живее в отделна колона по-долу).
• Дата на издаване — датата, на която доставчикът е издал документа. Във формат YYYY-MM-DD, защото това е форматът, с който Excel и почти всеки счетоводен софтуер се държат предсказуемо при импорт.
• Дата на данъчно събитие — отделна колона, защото при много фактури тя се различава от датата на издаване и точно тази дата определя в кой данъчен период попада сделката. При вътреобщностни доставки и при някои услуги разликата е оперативно значима.
• Доставчик — наименованието на контрагента, както е изписано на фактурата. Съхранявайте го като текст, без да го „почиствате“ автоматично; разликата между „ЕООД“ и „EООД“ с латинско Е се вижда само при сравнение срещу Търговския регистър.
• ЕИК — деветцифреният или 13-цифрен идентификатор на доставчика. Това е полето, по което срещате фактурата с реалния контрагент в Търговския регистър и в собствената си счетоводна номенклатура.
• ИН по ДДС — обикновено BG плюс 9 или 10 цифри за български доставчик, или съответен ЕС префикс за чуждестранен. Необходим е за вход по ДДС.
• Получател — наименованието на вашата компания, както е изписано на фактурата. Полезно за бърза проверка, че фактурата наистина е издадена на вас (типична грешка при доставчици с няколко клиента в групата).
• Данъчна основа — сумата преди ДДС. При повече от една ставка в един документ тук имате нужда от структура на ниво ред, не на ниво документ — повече за това в следващия раздел.
• ДДС ставка — 20%, 9%, 0% или съответната за обратно начисляване стойност. Оставете я като число с процент, не като текст.
• ДДС сума — изчисленият ДДС върху данъчната основа. Тази стойност отива в дневник покупки като входящ ДДС.
• Обща сума — крайната сума за плащане според фактурата. Това е стойността, която ще се сравнява срещу банковите плащания при равнение.
• Валута — BGN, EUR или друга. Никога не приемайте валутата мълчаливо от контекста; ако колоната липсва, мултивалутните партиди стават неразпознаваеми след факта.
• Курс — приложимият курс към BGN, обикновено БНБ фиксинг за датата на данъчното събитие. Подробностите за това как точно живеят BGN и EUR в една таблица са по-долу в самостоятелен раздел.
• Основание/описание — какво всъщност е било доставено. При услуги тук често стои базата за разпределение по разходен център или проект.
• Падеж — крайната дата за плащане. Това е оперативно поле, по което АП екипът подрежда платежния си календар.

Натрупаните колони изглеждат много, но всяка отговаря на конкретна задача: идентификация на документа, идентификация на контрагента, данъчно отчитане, валутно представяне, оперативно управление на плащането. Колона, която не отговаря на такава задача, може да отпадне; колона, която отговаря, не може да бъде сглобена обратно по-късно от концентрирани полета.

Изходно-ориентираният подход прави смисъл точно по тази причина. Когато колоните са фиксирани предварително, прегледът на партидата става механичен — филтрирате по Тип документ, проверявате сумите по доставчик, сравнявате Данъчна основа плюс ДДС сума срещу Обща сума. Когато всеки документ носи свой случаен набор от полета (както става, ако оставите AI инструмента да решава какво да извлече за всяка фактура поотделно), последващата работа изисква индивидуална преценка за всеки ред — точно това, от което извличането в Excel би трябвало да ви освободи.

На ниско ниво няколко настройки определят дали експортът на фактури в Excel за счетоводство ще премине гладко през импорта в Microinvest, Ажур, Plus Minus или каквато и да е друга счетоводна система. Датите трябва да са YYYY-MM-DD, не локалният формат на машината, която отваря файла; десетичните знаци за суми трябва да са консистентни (точка или запетая, но едно от двете в цялата партида); числовите полета трябва да са числа, а не текст, който само изглежда като число. Това не е Excel урок — това са трите неща, които правят разликата между импорт за две минути и половин ден чистене.

Един ред на фактура срещу един ред на артикул: кога кое работи

Решението между структура на ниво документ (header-level, един ред на фактура) и структура на ниво ред (line-item-level, един ред на артикул) е едно от тези, които струват малко предварително и много, ако се вземат след факта. Изборът зависи от това какво ще правите с таблицата, не от това колко детайлна искате да изглежда.

На ниво документ (header-level) получавате по един ред за цяла фактура — сумирана основа, сумиран ДДС, обща сума, валута, доставчик. Това е достатъчно, когато:

• подготвяте дневник покупки за месечно ДДС отчитане и нямате нужда да виждате отделните артикули;
• осчетоводявате AP по доставчик и сметката за разход е една и съща за цялата фактура;
• правите месечно равнение между фактурите и банковите плащания и работите с общата сума за плащане.

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

На ниво ред (line-item-level) получавате по един ред за всеки артикул или услуга от фактурата. Това е необходимо, когато:

• разпределяте разходите по категории (счетоводен ред на разходи, разходен център, проект, обект);
• работите в хотел или туристическа компания и една и съща фактура от доставчик на постелно бельо или хранителни продукти отива в няколко оперативни сметки според обекта или дестинацията;
• в един документ има смесени ДДС ставки — например 20% за стандартни услуги и 9% за нощувки в една и съща хотелска фактура. Структурата на ниво документ няма как да представи две различни ставки в един ред;
• държите следа от продуктови кодове, SKU или каталожни описания, за да правите анализ по продукт или услуга.

При работа на ниво ред задължително повтаряйте полетата от заглавната част на всеки ред — Номер на фактура, Дата на издаване, Доставчик, ЕИК, Валута. Без това повторение редът става безполезен в момента, в който филтрирате или сортирате. Excel не „помни“, че следващите пет реда принадлежат на същата фактура; всеки ред трябва да е самостоятелно полезен.

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

Едно предупреждение, което струва един уикенд: не правете смесена партида, в която част от фактурите са на ниво документ, а част на ниво ред. Това чупи последващия импорт, защото нито един счетоводен софтуер не приема смесена структура за един и същи входен файл. Решете предварително, попитайте се срещу коя от двете тестови ситуации работите за тази конкретна партида, и приложете единия подход за всички документи в нея.

Кредитни и дебитни известия в същата Excel таблица

Кредитните и дебитните известия трябва да живеят на същия лист като фактурите — не на отделен таб, не във втора таблица — иначе сумирането по доставчик и по период престава да дава нетния резултат. Работещото правило е просто и носещо: колоната Тип документ приема стойностите Фактура, Кредитно известие или Дебитно известие, а сумите се записват с подходящия знак.

За кредитни известия отрицателни стойности във Данъчна основа, ДДС сума и Обща сума. За дебитни известия, които са в полза на доставчика, положителни стойности (същата посока като фактура). Това звучи дребно, но има оперативна последица: при тази конвенция една обикновена SUM формула върху колоната с обща сума за един доставчик за един месец веднага дава нетното задължение след всички корекции — без условни сборове, без отделни обходи на листа. Същото важи за Данъчна основа при подготовка на дневник покупки.

Втора колона, която често липсва в реални Excel-и, но прави цялата разлика при одит или ревизия: референция към оригиналната фактура. Кръстете я Референция към фактура или Свързан документ — името няма значение, наличието има. Тази колона носи Номер на фактура на първоначалния документ, който известието коригира. Без нея кредитното известие виси без контекст и счетоводителят не може да проследи коя сделка е била коригирана.

Точно тук попада темата за извличане на кредитни известия в Excel. AI извличането трябва изрично да получи правилото за подписани суми и за референцията към оригиналния документ в самия промпт, иначе по подразбиране ще се опита да третира кредитното известие като фактура — с положителни суми и без свързване към оригинала. Промптът, който задава цялата схема, е тема на по-долен раздел; засега е достатъчно да знаете, че това правило не е автоматично — то се описва.

Конкретните български случаи, в които срещате тази структура:

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

Оперативната полза от тази структура се вижда веднага. Прегледът на цял месец става въпрос на филтър по Тип документ равно на Кредитно известие и проверка дали всяко от тях има непразна референция и отрицателни суми. Една невалидна стойност изскача без да я търсите.

BGN, EUR и ДДС ставки в една и съща таблица

Реалните български партиди от доставчически фактури рядко са едновалутни. EUR от европейски доставчик, BGN от местен, понякога USD или GBP за софтуерни услуги — всичко това стига до един и същ лист и трябва да съществува там, без да чупи нито дневник покупки, нито анализа по разходен център.

Работещата структура е двойка колони. Валута носи оригиналната валута на документа — BGN, EUR или каквато е реално напечатана на фактурата. Сумите във Данъчна основа, ДДС сума и Обща сума остават в тази оригинална валута. Курс носи приложимия курс към BGN. Когато ви трябва нормализиран изглед — например за единен сбор на разходите по разходен център — добавяте допълнителни колони Данъчна основа BGN и Обща сума BGN, които се изчисляват от оригиналните стойности и курса с обикновена Excel формула. Двата изгледа съществуват едновременно, без единият да изтрива другия.

Курсът има две възможни произходи. Първият е самата фактура — някои доставчици изрично декларират курса, по който са изчислили еквивалентни стойности. Когато това е така, използвайте него; той е документираният курс за тази сделка и съответства на това, което доставчикът е отразил при себе си. Вторият произход, който се прилага в останалите случаи, е БНБ фиксингът за датата на данъчното събитие. Това е оперативно работещата база за български контекст: данъчното отчитане се извършва срещу него, и счетоводителят не трябва да отговаря на въпрос откъде идва курсът ви.

Втората измерима реалност в български фактури е, че ДДС ставка често варира между редовете на един и същи документ. Хотелска фактура смесва 9% за нощувки и 20% за консумации в ресторанта. Сервизна фактура може да има 20% за труд и 0% за вътреобщностно превозвани части. Структурата на ниво документ няма как да представи две различни ставки коректно в един ред — там колоната ДДС ставка приема една стойност и компромисите започват. Когато виждате смесени ставки, на ниво ред от предишния раздел не е препоръка, а изискване.

Това е и моментът, в който фактури с ДДС в Excel стават полезна структура, а не просто архив. Когато ДДС ставката стои в отделна колона за всеки ред, можете да:

• филтрирате по ставка и да видите цялата основа по 9% за месеца;
• сумирате основата по ставка за дневник покупки без условни формули;
• получите коректен общ входящ ДДС за периода с проста pivot таблица.

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

• Обратно начисляване при вътреобщностна доставка — фактурата идва без начислен ДДС, защото задължението е на получателя. Маркирайте го изрично, или в отделна колона Режим на ДДС, или като стойност в Основание/описание. Иначе фактурата изглежда като нулева ДДС грешка.
• Нулева ставка при износ — изглежда подобно, но не е същото. Дръжте ги различими, поне в основанието.
• Освободени доставки (някои финансови, образователни, медицински услуги) — нулев ДДС, но с различно нормативно основание. Когато ги имате редовно, добавете колона за основанието; когато са изключение, основанието в Основание/описание е достатъчно.

Това не е изчерпателен преглед на режимите по ЗДДС — това е минималната структура, която позволява таблицата да отрази реалността, без вие да преписвате правилата за всеки случай.

Български реквизити и бързи проверки преди да изпратите файла

Преди да изпратите готовия Excel на счетоводител или да го импортирате в счетоводната система, един кратък QC обход по самата таблица хваща повечето грешки, които иначе биха се върнали като въпроси или като отказан импорт.

Първата проверка е срещу задължителното съдържание на българска фактура — какво трябва да присъства в самия документ и съответно да бъде извлечено в реда. По практиката на ЗДДС това са:

• номер и дата на издаване;
• идентификация на доставчика — наименование и адрес, ЕИК, ИН по ДДС когато доставчикът е регистрирано лице;
• идентификация на получателя — вашата компания;
• данъчна основа;
• ДДС ставка и сума, или указание за нулева ставка / обратно начисляване / освободена доставка с основанието за това;
• обща сума;
• основание или описание на сделката;
• дата на данъчното събитие, когато се различава от датата на издаване.

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

Втората проверка е върху самите извлечени стойности. Тези тестове се правят с прости Excel формули, не визуално — при партида от стотици документи визуалният преглед не е реалистичен:

• Формат на ЕИК. 9 или 13 цифри, без интервали и без знаци. Бърза филтрация по дължина на стринга открива OCR грешки, в които буква е разчетена като цифра или обратното.
• Формат на ИН по ДДС. BG плюс 9 или 10 цифри за български доставчик, или съответен ЕС префикс плюс национален формат за чуждестранен. Стойност без префикс или с грешен брой цифри почти винаги е разчетена грешно.
• Правдоподобност на ДДС ставката. В България обичайните стойности са 20%, 9% и 0% (последното често с указание за обратно начисляване или износ). Всяка друга стойност изисква проверка — обикновено е грешка в разпознаването или пропусната десетична запетая.
• Съвпадение на сборовете. Колона Проверка сбор с формула =Данъчна основа + ДДС сума - Обща сума трябва да дава нула за всеки ред, с допустима толерантност от 0.01 BGN или EUR за закръгляне. Стойности по-големи от тази толерантност са знак, че едно от трите полета е сгрешено.
• Сумиране на редовете срещу заглавната част. Когато работите на ниво ред, сборът на стойностите по линиите за всяка фактура трябва да съвпада със стойностите от заглавната ѝ част. Една pivot таблица за минута показва разминаванията.
• Дата на данъчно събитие при сделки от чужбина. Това поле често липсва, защото на чуждите фактури не винаги се появява изрично, но за български данъчни цели често е именно то, което определя периода на отчитане. Когато колоната е празна за вътреобщностни доставки, проверете ръчно.

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

---

Български промпт, който описва точно желания изход

Сега, когато схемата е ясна, въпросът „как я получавам в действителност“ има директен отговор. Описвате я на естествен български към AI инструмент за извличане, в един промпт, който носи всички решения, които статията изгражда. Ето как изглежда такъв промпт:

Обработи приложените фактури, разписки и кредитни известия. Извлечи следните колони, в този ред:

Тип документ, Номер на фактура, Дата на издаване, Дата на данъчно събитие, Доставчик, ЕИК, ИН по ДДС, Получател, Данъчна основа, ДДС ставка, ДДС сума, Обща сума, Валута, Курс, Референция към фактура, Основание/описание, Падеж.

Правила:

• Един ред на документ.
• Тип документ: Фактура, Кредитно известие или Дебитно известие. За кредитни известия задай отрицателни стойности на Данъчна основа, ДДС сума и Обща сума.
• При кредитно или дебитно известие попълни Референция към фактура с номера на оригиналната фактура, която документът коригира; за обикновени фактури остави полето празно.
• Дати във формат YYYY-MM-DD. Ако Дата на данъчно събитие не е изрично указана, остави я празна (не я приравнявай автоматично към Дата на издаване).
• Валутата е BGN, EUR или каквато е напечатана на самия документ. Не я преобразувай.
• Курс: ако фактурата изрично декларира курс към BGN, използвай него; ако не, остави полето празно.
• ЕИК: 9 или 13 цифри, без интервали.
• ИН по ДДС: с префикс на страната.
• Пропусни страници, които не са фактури, разписки или известия — например имейл придружителни писма, обобщителни страници, бланкови съобщения.
• Изход: Excel.

Този промпт работи не защото инструментът „познава“ български счетоводен формат, а защото описанието е точно. Именуваните колони стават заглавия в изходната таблица в същия ред; правилата за Тип документ и за подписаните стойности при кредитни известия пристигат еднозначно, не като подсказка; формата на датата и форматът на ЕИК са указани, не подразбрани. Не се изисква шаблон, не се изисква обучение върху примерни фактури, не се изисква предварителна настройка на полета. Самият промпт е конфигурацията.

Точно това прави подхода различен от класическата OCR настройка, в която всяко поле се привързва към координати или regex шаблон. Тук автоматизирано извличане на данни от фактури се случва, защото описанието на изхода на естествен език е достатъчно богато, за да обхване и решенията за документен тип, и правилата за подписани суми, и форматирането на стойностите. Обработката на входящи фактури с AI в практиката си се свежда точно до това: вие управлявате обработката чрез промпта, а не чрез интеграция в ERP.

Същият промпт се справя със смесена партида от източници. Папката, която качвате, може да съдържа PDF от имейл, JPG снимка от телефон, сканиран TIFF от куриерска поща — и всичко това в една и съща задача. Точно тук работи автоматичната обработка на фактури с OCR: разчитането на сканирани документи и снимки върви заедно с AI разбирането на структурата, не вместо него. Колоната Тип документ плюс еднаквият набор останали колони е това, което прави партида с фактури, разписки и кредитни известия в нея управляема — всеки документ намира мястото си в схемата, без отделен лист за всеки тип.

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

За по-широк контекст — извън конкретно българската специфика — съществува отделно по-широко англоезично ръководство за конвертиране на PDF фактури в Excel, което покрива общите принципи на работния процес и е полезно ако работите и с международни клиенти.

Самият инструмент, който статията описва на ниво работен процес, е Invoice Data Extraction. Интерфейсът е едно поле за промпт и зона за качване на файлове — същата схема, по която работите с ChatGPT или Claude — без шаблони, без магьосници за настройка, без многостъпкови форми. Качвате смесена папка с PDF, JPG и PNG — достатъчно за месечна партида дори при няколко десетки доставчика, или за многомесечен архив наведнъж, ако ви предстои такова събиране. Описвате на български желаните колони по същия начин като в примера по-горе и изтегляте Excel, CSV или JSON. Запазвате промпта в библиотеката с промпти, за да го прилагате към следваща партида с едно действие. Това е целият работен процес — без обещание за заместване на счетоводителя и без претенция за гарантирано ДДС съответствие; продуктът подготвя структурираните данни, а проверката, осчетоводяването и съответствието остават при специалиста.

Кога извличане в Excel е достатъчно и кога ви трябва пълна AP или счетоводна платформа

Excel-базираният извлекателен работен процес е работещ за повече ситуации, отколкото вендорските продуктови страници обикновено признават — но не за всички. Полезно е да знаете предварително в коя ситуация попадате, за да не построите процес, който се разпада при обема, който ви предстои.

Excel изходът е достатъчен, когато:

• подготвяте дневник покупки и месечно ДДС отчитане за самостоятелен бизнес или малка фирма с няколко десетки до около сто фактури месечно;
• изграждате партида за импорт в съществуваща българска счетоводна система — Microinvest, Бизнес Навигатор, Ажур, Plus Minus или друга — която приема Excel или CSV вход и сглобява осчетоводяването от там;
• работите в бутиков счетоводен офис, който обслужва няколко клиента, и искате повторяем процес: един промпт на клиент в библиотеката, една партида на месец, един импорт;
• сте в хотелски или туристически финансов офис, който прави месечна обработка на доставчически фактури и иска бърз контрол върху сумите по доставчик и по обект, преди номерата да отидат към главния счетоводител. За туроператорската специфика — фактури от хотели, транспорт, екскурзоводи, застраховки и билети, групирани по екскурзия и валута — вижте отделното ръководство за подреждане на разходните фактури на туроператор в Excel по екскурзия и доставчик.

В тези ситуации Excel плюс прецизен промпт замества хората да набират ръчно, без да задължава екипа да въвежда нова платформа.

Excel изходът няма да е достатъчен, когато:

• провеждате тристранно съответствие между поръчка, доставка и фактура за всеки документ — това изисква активна интеграция между AP, склад и снабдяване в реално време;
• имате вътрешни процеси по одобрение и маршрутизация на фактурите по подписващи лица, с изискване за пълна аудиторска следа кой какво е одобрил и кога;
• осчетоводявате директно в главна книга, не през импорт — където всеки документ става ред в счетоводна система в момента на въвеждането;
• интегрирате обработката с ERP в реално време, за да захраните анализи, прогнози и платежни решения с актуални данни.

В тези ситуации Excel не е грешен изход — той е междинна стъпка, която рано или късно ще се размени за платформена. AP/счетоводните платформи добавят оркестрация над извличането, а самото извличане остава ядрото.

Това не е „или, или“ решение. Много екипи започват с Excel-базиран подход за месечната обработка, изграждат вътрешно доверие в работещите промпти и колонни схеми, и после интегрират извличането в по-широка платформа, когато обемът или сложността го изискват. Промптите и схемата, които сте изградили, остават валидни — те се пренасят като входни данни към платформата, не като захвърлен труд. По-широк преглед на автоматизационните модели за Excel-базираната обработка извън конкретно българския контекст разглежда автоматизиране на въвеждането на данни от фактури в Excel в самостоятелна статия.

Едно нещо остава общо в двата режима. Дори когато надскочите Excel работния процес и преминете към платформа, разпознаването на фактури с OCR в България — разчитането на български документи с техните Cyrillic-имена на доставчици, формат на ЕИК и ИН по ДДС, и реалии на ДДС режима — остава ядрото на оптимизацията. То просто се вгражда в по-голяма структура, а не изчезва.