Рахунок може бути бездоганним з юридичної точки зору, але фінансово марним, якщо ніхто не може відповісти на два питання: Чи був він прийнятий? та Коли саме його сплатили?. Нові рамки B2B електронного виставлення рахунків в Іспанії створені для того, щоб зробити ці відповіді машиночитаними. Для бізнесу це означає, що проєкт не обмежується заміною PDF-вкладень на структуровані файли. Це також про об'єднання продажних рахунків, кредиторської заборгованості, банківської активності та підтвердження платежів в єдиний надійний робочий процес.
Рамки були опубліковані у 2026 році, але для багатьох підприємств ще немає фіксованої календарної дати. Відлік часу на впровадження починається, коли набирає чинності міністерський наказ, який запроваджує публічне рішення для електронного виставлення рахунків. Починаючи з цього тригера, підприємства, чий оборот за попередній рік перевищив 8 мільйонів євро, мають 12 місяців, а решта — 24 мсяці. Цього часу вистачить, якщо ставитися до цього як до проєкту з бухгалтерського обліку та операційної діяльності, а не як до купівлі програмного забезпечення в останній момент.
Цей посібник пояснює, що змінює правило, як визначити, який дедлайн застосовується, і як створити робочий процес відстеження статусу оплати, який буде надійним при переміщенні рахунків між різними платформами.
Що саме вимагають нові рамки Іспанії
Рамки застосовуються до підприємств та фізичних осіб-підприємців, які вже зобов'язані виставляти рахунки, коли замовником є інше підприємство або підприємець, що має своє місцезнаходження, постійне представництво, зареєстроване місце проживання або місце проживання в Іспанії, а операція адресується за цією іспанською адресою.
Зобов'язання є ширшим, ніж «надіслати замовнику електронну копію». Рахунок має бути структурованим електронним повідомленням, яке може бути оброблене програмним забезпеченням. Дозволені синтаксиси включають:
- CII
- UBL
- EDIFACT
- Facturae
Модель даних має відповідати семантичній моделі EN 16931 з адаптаціями, визначеними іспанськими правилами. Кожен рахунок також повинен мати унікальний ідентифікатор, який включає податковий ідентифікаційний номер емітента, номер і серію рахунку, а також дату виставлення.
Система має два взаємопов'язані рівні:
- Приватні платформи обміну, які маршрутизують рахунки між емітентами та отримувачами.
- Публічне рішення для електронного виставлення рахунків, розроблене та підтримуване Податковим агентством Іспанії, яке виступає універсальним сховищем і надає послуги з відстеження платежів.
Підприємство може використовувати приватну платформу, публічне рішення або їх комбінацію. Якщо воно не домовилося з постачальниками про приватну платформу для отримання рахунків, публічне рішення використовується за замовчуванням. Якщо воно все ж таки обирає приватну точку отримання, воно повинно повідомити про це у своїх ділових комунікаціях та, якщо застосовно, на своєму веб-сайті.
Ось чому окремого екрану для виставлення рахунків, найімовірніше, буде недостатньо. Система повинна правильно ідентифікувати контрагента, створювати прийнятний структурований формат, маршрутизувати документ, зберігати його цілісність та фіксувати подальші стани рахунку.
Який дедлайн застосовується до вашого бізнесу?
Офіційне набрання чинності декретом відрізняється від його практичного застосування. Його операційні вимоги відкладаються до набуття чинності міністерським наказом щодо публічного рішення. Після набуття чинності цим наказом:
- Підприємства, у яких обсяг операцій за попередній календарний рік перевищив 8 мільйонів євро, входять у рамки через 12 місяців.
- Інші підприємства та підприємці — через 24 місяці.
Не розраховуйте свій дедлайн, додаючи рік або два до дати публікації декрету в Офіційному віснику Іспанії. Відповідним тригером є виконавчий наказ, а тест на оборот використовує безпосередньо попередній календарний рік. Тому підприємство, яке перевищило поріг, повинне щороку фіксувати показник, використаний в оцінці, а не покладатися на неформальну оцінку.
Існує також перехідне правило щодо читабельності. Протягом 12 місяців після набуття чинності рамок для підприємства з порогом понад 8 мільйонів євро, таке підприємство, як правило, повинне супроводжувати свої електронні рахунки PDF-файлом, який гарантує можливість їх прочитати отримувачем, якщо отримувач прямо не погодився отримувати їх в оригінальному форматі. Цей PDF є мостом для зручності використання, а не заміною структурованого рахунку.
Декрет також надає малим підприємствам додатковий перехідний період для звітування про стан рахунків. Для фізичних осіб та певних організацій, що розподіляють дохід, які перебувають на рівні 8 мільйонів євро або нижче, положення про державну звітність стають обов'язковими через 12 місяців з дати набуття чинності декретом для відповідної групи. Оскільки ці переходи взаємодіють, зафіксуйте дати-тригери та тип вашої організації разом із вашим іспанським податковим радником.
Зобов'язання щодо статусу оплати є операційним наріжним каменем
Найважливішою зміною для фінансових відділів є те, що статус рахунку стає визначеним потоком даних.
Отримувач зобов'язаний повідомляти принаймні про:
- Комерційне приймання або відхилення із зазначенням дати.
- Повну фактичну оплату із зазначенням дати фактичної оплати.
Отримувач також може повідомляти про часткове приймання або відхилення, часткову оплату та суму, а також про переуступку рахунку третій особі для стягнення або оплати. Ці додаткові статуси можуть бути цінними для контролю за кредитними ризиками, але вони не замінюють обов'язкової події повної оплати.
Інформація про статус, як правило, має надсилатися протягом чотирьох календарних днів з моменту події, за винятком суботи, неділі та національних свят. Для публічного рішення отримувач повинен повідомити про повну фактичну оплату кожного отриманого рахунку, який не був відхилений, а також дату оплати, незалежно від того, чи проходив рахунок через приватну платформу. Отримувач також повинен повідомити дату настання терміну платежу.
Це створює коротке вікно контролю. Банківська звірка, проведена через тижні після кінця місяця, може бути достатньо хорошою для управлінської звітності, але вона занадто повільна, щоб бути єдиним механізмом, який повідомляє систему виставлення рахунків про здійснення платежу. Вашому процесу обробки кредиторської заборгованості потрібна подія або черга, яка помічає банківське підтвердження, зіставляє його з рахунком та вчасно надсилає необхідний статус.
Ретельно визначте поняття «оплачено»
Фактична дата оплати не обов'язково є датою, коли хтось натиснув «оплачено» у бухгалтерській програмі. Це пов'язано з фактичним отриманням коштів постачальником. Для переказу це, як правило, означає дату списання коштів з рахунку платника. Для оплати готівкою — це дата внесення готівки. Для узгодженого зарахування зустрічних вимог — це дата такого зарахування.
Пропозиція рахунку для факторингу або іншого механізму дострокового інкасо сама по собі не робить його оплаченим. Відповідна дата — це дата фактичного отримання коштів постачальником. Ця різниця має значення, коли ваш бізнес використовує факторинг, знижки постачальників (снабженческие фінанси), банківські картки або посередника, який повідомляє про платіж до того, як базові кошти надійдуть постачальнику.
Включіть ці визначення у свої правила зіставлення. Як мінімум, зберігайте:
- Ідентифікатор рахунку та податковий номер постачальника
- Дату виставлення, дату надання послуг або доставки та дату отримання
- Договірні та розрахункові дати платежу
- Статус приймання або відхилення з міткою часу
- Суму платежу, ідентифікатор банківської операції та фактичну дату розрахунку
- Показники повної, часткової, оскаржуваної, переуступленої оплати та скасування оплати
- Платформу або канал передачі кожної події
Якщо платіж було повернуто або неправильно застосовано, не перезаписуйте оригінальну подію мовчки. Збережіть оригінальну операцію, зафіксуйте виправлення та надішліть рахунок на перегляд. Аудиторський слід корисніший, ніж зелена позначка «оплачено», яка вже не пояснює, що сталося.
Пов'яжіть правило з іспанськими правилами щодо умов оплати
Електронна звітність не створює нових підстав для затримки платежу. Іспанські правила щодо комерційних затримок платежів, як правило, встановлюють 60-денний граничний термін оплати між підприємствами з особливими правилами щодо початку перебігу строку та процедур приймання. Постачальники, як правило, повинні надати рахунок-фактуру або аналогічну вимогу про оплату протягом 30 днів з моменту отримання товарів або послуг. Електронне отримання може розпочати розрахунок терміну оплати, якщо гарантовано ідентичність, автентичність, цілісність та отримання рахунку.
Практичний висновок простий: зберігайте дати, які визначають терміни оплати, а не лише дату, надруковану на рахунку. Рахунок-фактура з відсутньою датою надання послуг, незафіксованою датою отримання або задокументованим етапом приймання може ускладнити розрахунок дати платежу.
Щодо дебіторської заборгованості, застосовуйте ту саму дисципліну. Ваша книга продажів повинна показувати, коли клієнт отримав рахунок, прийняв або відхилив його, і коли надійшли кошти. Це дає менеджеру зі стягнення заборгованості обґрунтовану наступну дію, а не лише звіт про строки, заснований лише на датах виставлення рахунків.
Система бухгалтерського обліку, яка може впоратися з чотириденним вікном
Ви можете підготувати процес до вибору платформи. Почніть із простої моделі станів для кожного рахунку:
1. Створення та перевірка
Згенеруйте рахунок із перевіреного запису про клієнта. Перед передаванням перевірте податкові номери, обов'язкові поля рахунку, унікальний ідентифікатор, суми за позиціями, податковий режим, валюту та дати платежу. Відхилити некоректні документи на етапі створення дешевше, ніж вирішувати відхилення платформи після того, як клієнт уже отримав неповний запис.
2. Передавання та збереження підтвердження
Надішліть через вибрану приватну платформу або публічне рішення. Зберігайте відповідь про передавання, пункт призначення, позначку часу та точну структуровану версію документа або геш вмісту. Якщо платформа перетворює повідомлення CII, UBL, EDIFACT або Facturae, зберігайте оригінал і перетворене зображення або надійне посилання між ними.
3. Фіксація приймання або відхилення
Спрямовуйте комерційну відповідь отримувача в книгу обліку рахунків. Відхилення має створювати код причини та відповідального, а не лише червону позначку. Якщо необхідне виправлення, виставте відстежуваний виправний рахунок та збережіть зв'язок з оригіналом.
4. Зіставлення розрахунку з рахунком
Імпортуйте банківські операції досить часто, щоб встигнути у звітне вікно. Зіставляйте за ідентифікатором рахунку, контрагентом, сумою та реквізитами переказу, з чергою на перевірку для часткових платежів, пакетних платежів, комісій та курсових різниць. Особа чи процес, які підтверджують зіставлення, мають бути видимими в журналі аудиту.
5. Звіт про платіжну подію
Коли рахунок повністю оплачений, зафіксуйте фактичну дату ефективного платежу та надішліть необхідну подію протягом чотирьох робочих днів. Не використовуйте дату виписки, якщо вона відрізняється від дати розрахунку. Якщо платформа уповноважена звітувати від вашого імені, збережіть авторизацію та результат доставки.
6. Звірте книги обліку та реєстр статусів
Наприкінці періоду порівняйте реєстр рахунків-фактур, повідомлення платформи, банківську активність, залишки дебіторської/кредиторської заборгованості та зазначені статуси. Дослідіть рахунки, які позначені як сплачені в одній системі, але залишаються відкритими в іншій. Ця звірка також допомагає виявити дублікати рахунків, відсутні кредит-ноти та платежі, віднесені не на той суб'єкт.
Типові помилки, яких слід уникати
Розгляд PDF як електронного рахунку
Можливо, PDF можна прочитати, але він не обов'язково є структурованим рахунком. Зберігайте будь-який перехідний PDF як допоміжний засіб, водночас роблячи відповідну вимогам структуровану версію обов'язковим записом.
Припущення, що приватна платформа знімає державну звітність
Приватні платформи повинні брати участь в іспанській системі та взаємодіяти з іншими. Що більш важливо для отримувачів, про повну оплату все одно необхідно повідомляти в публічне рішення згідно з декретом, навіть якщо обмін відбувався через приватну платформу.
Використання дати виставлення як єдиної дати
Дата виставлення, доставки або надання послуг, отримання, приймання, сплати, розрахунку та звітності відповідають на різні питання. Поєднання їх в одне поле «дата рахунку» знищує докази, необхідні вашому платіжному процесу.
Звіт про «оплату», коли кошти лише заброньовані
Доступність факторингу, запланований переказ або внутрішнє погодження не є ефективним платежем. Дочекайтеся події, яка означає отримання коштів постачальником, а потім зафіксуйте цю дату.
Нез'ясованість права власності на платформу
Визначте, хто відстежує збійні передачі, відхилені рахунки, незвітовані платежі та незіставлені банківські операції. Платформа може автоматизувати транспортування; вона не може вирішувати, хто відповідає за помилку, якщо ви не визначите цю відповідальність.
Практичний контрольний список готовності
До вашого дедлайну переконайтеся, що можете відповісти «так» на кожне запитання:
- Чи можемо ми визначити, чи підпадає кожен клієнт і постачальник під дію іспанських B2B рамок?
- Чи знаємо ми, чи відносить нас наш оборот до фази 12 чи 24 місяців?
- Чи може наша система виставлення рахунків створити повідомлення, сумісне зі структурованою EN 16931, у прийнятному синтаксисі?
- Чи є наша точка прийому публічною та перевіреною з основними контрагентами?
- Чи можемо ми зберегти оригінал рахунку та кожну перетворену чи передану версію?
- Чи фіксуємо ми окремо приймання, відхилення, дату оплати, часткову та повну оплату?
- Чи може банківські дані надходити до реєстру рахунків протягом чотирьох робочих днів?
- Чи надсилаються повернення платежів, кредит-ноти та оскаржувані рахунки на ручний перегляд?
- Чи можемо ми звірити статуси платформи з головною книгою та банківською випискою?
- Чи є у нас задокументований відповідальний за збої та зберігання доказів?
Якщо будь-яка відповідь «ще ні», почніть з цього. Малий бізнес часто може досягти значного прогресу за допомогою чистого реєстру рахунків, дисциплінованого імпорту банківських виписок і чітких черг на виправлення ще до впровадження великої платформи.
Спрощення керування вашими фінансами
Перехід на електронні рахунки в Іспанії підвищує цінність надійних записів: вам потрібно пов'язати те, що було виставлено, прийнято, сплачено, про що звітовано. Beancount.io пропонує фінансовий облік у вигляді звичайного тексту, який є прозорим, керується системами контролю версій та готовий до використання зі штучним інтелектом, щоб ваша фінансова історія залишалася доступною для перевірки з розвитком вашого робочого процесу виставлення рахунків. Ознайомтеся з документацією або використовуйте Fava для візуалізації звірень.