Разбираем, что такое VeriFactu в Испании

VeriFactu — это подход к фиксации данных о счетах и продажах в Испании, при котором учетная система создает защищенные записи и работает по правилам налогового контроля. Суть в том, как система создает, хранит и, в зависимости от модели работы, передает данные об операциях.

Для владельца бизнеса это практический вопрос. Если продажи проходят через кассу, CRM, интернет-магазин или учетную систему, нужно понять, где формируется финальный счет и соответствует ли этот контур требованиям к записям. Иначе можно купить сервис, который будет дублировать данные, или привязать процессы к платформе, из которой сложно выгрузить историю продаж.

VeriFactu не заменяет бизнес-логику компании. Он устанавливает требования к следу операции: запись должна быть последовательной, защищенной от незаметного редактирования и пригодной для налогового контроля. Поэтому начинать стоит со схемы движения данных: от заказа к счету, оплате и учету.

Что такое VeriFactu?

Правила фиксации операций

VeriFactu описывает правила работы программного обеспечения, которое фиксирует данные о счетах и продажах для налогового контроля в Испании. Это не продукт, который можно просто подключить, и не название конкретной CRM, кассы или платежного сервиса.

Речь идет о свойствах контура, в котором появляется финансовый документ. Система должна сформировать запись операции, сохранить ее последовательность и не позволять незаметно переписывать историю.

Продажа проходит через цепочку событий. Заказ появляется в интернет-магазине или CRM. Оплата проходит через кассу или платежный сервис. Затем формируется счет. VeriFactu касается момента, когда операция становится учетной записью: что именно система зафиксировала, как связала запись с предыдущими операциями и что происходит, если документ нужно исправить или отменить.

Не стоит путать VeriFactu с электронным счетом. Электронный счет определяет форму документа и способ его обмена. VeriFactu определяет, есть ли за этим документом надежный след в системе.

CRM тоже не обязательно создает финальный счет. Она может быть местом, где менеджер ведет сделку. О ее роли в продажах читайте в материале Что такое CRM-система простыми словами.

Вопрос для бизнеса простой: какая система создает окончательную запись о продаже и может ли она хранить ее без тихого редактирования задним числом.

Зачем VeriFactu нужен бизнесу и налоговому контролю

Прослеживаемость финансовых документов

Счет или продажа не должны исчезать из учета после оформления. Их также нельзя тихо переписать задним числом так, будто первоначальной записи не существовало. VeriFactu устанавливает требования к следу, который операция оставляет в программном контуре бизнеса.

Для налогового контроля важны прослеживаемость операций и целостность записей. Должно быть понятно, что продажа состоялась, какой документ сформировали и как система обработала отмену или исправление.

Смысл в том, чтобы история финансовых документов не зависела от возможности вручную изменить запись без следа.

Бизнесу такой подход тоже полезен. Он заставляет честно разложить контур данных: какая система создает финальный счет, где хранится история документов, кто может менять статус операции и что передается между кассой, CRM и учетом.

VeriFactu не исправит автоматически ошибку в сумме, налоге или данных покупателя. Ошибка может возникнуть. Но правильный процесс не стирает ее бесследно: система должна сохранять логику исправления, а не подменять прошлую операцию новой версией.

Когда роли систем определены, проще обсуждать автоматизацию и интеграции без лишних модулей и дублирования документов.

Как работает VeriFactu: путь счета от продажи до записи

От продажи до записи

Всё начинается с события, которое система может распознать как продажу или оказание услуги. Неважно, где оно возникло: в кассе, CRM, интернет-магазине или учётной системе. Важно, какая из этих систем превращает событие в финальный счёт и учётную запись.

1234567891011121314151617<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 160" role="img" aria-label="Схема руху даних від продажу через рахунок до захищеного запису та збереження або передавання">
  <defs>
    <marker id="arrow" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto">
      <path d="M0,0 L0,6 L9,3 z" fill="#4A5568"/>
    </marker>
  </defs>
  <rect x="30" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M140 80 H190" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="200" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M310 80 H360" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="370" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M480 80 H530" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <circle cx="570" cy="80" r="30" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M600 80 H650" stroke="#4A5568" stroke-width="3" marker-end="url(#arrow)"/>
  <rect x="660" y="55" width="100" height="50" rx="8" fill="#E2E8F0" stroke="#4A5568" stroke-width="2"/>
  <path d="M570 50 C540 15 450 15 420 50" fill="none" stroke="#4A5568" stroke-width="2" stroke-dasharray="6 6" marker-end="url(#arrow)"/>
</svg>

Продажа создаёт событие, на его основе формируется счёт, а система фиксирует операцию отдельной записью. Эта запись не должна существовать изолированно. Она связывается с предыдущими записями, чтобы историю нельзя было незаметно подменить или переписать задним числом. Затем данные сохраняются в системе или передаются по поддерживаемой ею модели.

Есть граница, которую часто упускают при проектировании процесса. Черновик счёта можно редактировать до оформления: менять позиции, данные покупателя или условия продажи. Но после фиксации операции изменение не должно стирать исходный след.

Если счёт нужно отменить или исправить, система должна отразить это действие и его связь с предыдущим документом. Именно здесь видна разница между редактированием черновика и изменением уже оформленной операции.

Проблемы начинаются, когда касса, CRM и учётная система каждая по-своему считают себя местом формирования финального счёта. Тогда одна продажа порождает несколько документов с разными статусами. Нужен единый источник истины, а остальные системы должны получать нужные данные через согласованную синхронизацию.

Что такое электронный счёт и чем он не является для VeriFactu

Форма документа и запись

Электронный счёт — это счёт, созданный, переданный или полученный в электронном формате. Он описывает форму документа и способ обмена им между продавцом, покупателем, бухгалтерией или другой системой.

Документ может прийти по почте, через кабинет сервиса или автоматически попасть в учётную систему. Но сам электронный формат не объясняет, как система хранит историю операции.

VeriFactu относится к другому уровню. Его предмет — правила формирования учётной записи и целостность данных о продаже. Электронный счёт может быть способом передать документ. VeriFactu определяет, что происходит с операцией в системе после оформления: сохраняется ли след, видны ли исправления и не исчезает ли исходная запись.

CRM часто путают с учётной системой, потому что в ней уже есть клиент, товары и сумма сделки. Но её роль другая: она ведёт процесс до продажи и после неё. О границах CRM читайте в материале Что такое CRM-система простыми словами.

Не назначайте систему ответственной только потому, что она первой показала сумму. Источник финального счёта определяют по тому, где операция окончательно оформляется, корректируется и остаётся в истории.

Как проверить кассу, CRM и учет перед интеграцией VeriFactu

Карта движения данных

Начните с карты текущего контура. Перечислите все системы, через которые проходит продажа: сайт, кассу, CRM, платежный сервис, учетную систему, склад или личный кабинет внешней платформы.

Для каждой отметьте, какие данные она создает, получает, изменяет и хранит. Такая карта быстро покажет, где появляются дубликаты и в каких местах информация теряет связь с исходной операцией.

Затем определите место, где формируется итоговый счет. Это не обязательно касса или CRM. Ответственная система должна оформлять операцию, хранить ее статус и обрабатывать последующие корректировки. Если итоговый документ создается в одном контуре, другие системы не должны самостоятельно создавать его копии.

Проверьте, передаются ли между системами номер операции, сумма, налоговые данные и статус отмены. Недостаточно синхронизировать название товара и контакт покупателя. Без статусов и связей между документами в учет может попасть продажа, которую уже вернули или исправили в другом контуре.

Отдельно выясните, кому принадлежит история операций. Данные должны быть доступны для экспорта, а не оставаться только в интерфейсе закрытого сервиса. Также нужно описать сценарии возврата, отмены и исправления: какая система запускает действие, куда передается изменение и какой документ остается в истории.

Когда VeriFactu может не быть прямой задачей бизнеса

Границы ответственности систем

Необходимость менять собственную систему зависит от роли бизнеса в цепочке продаж. Нужно выяснить, формируете ли вы итоговый счет в своем контуре или это делает другая сторона.

Если счет появляется на внешней платформе, бизнес может передавать ей данные о заказе, но не создавать саму запись операции. Тогда нужно определить границу ответственности между собственной системой и платформой.

Сайт тоже может быть только витриной. Он показывает каталог, принимает заявку или ведет покупателя в другой канал оплаты, но не оформляет продажу и не выставляет счет. В таком случае проверять нужно не сайт, а систему, где заказ превращается в финансовый документ.

Бывает, что CRM фиксирует сделку, а учет ведется в отдельном контуре. Ответственную систему определяют не по названию сервиса, а по действию: где операция окончательно оформляется, меняет статус и остается в истории.

Это не значит, что требования можно игнорировать. Сначала нужно определить ответственного за формирование записи. Состав проверки зависит от систем и сценариев обмена данными, а не от популярности платформы. Это влияет и на стоимость интеграции кассы, CRM и учетной системы.

Ошибки при подготовке к VeriFactu

Экспорт и корректировка данных

Электронный счёт тоже легко спутать с защищённой записью о продаже. Цифровой документ нужен для обмена данными с получателем. Он не показывает, как система хранит последовательность операций и что происходит после отмены или исправления. Для каждого сценария стоит определить ответственную систему и маршрут изменения.

Ещё одна ошибка — хранить историю только в закрытом сервисе. Если данные нельзя экспортировать, сложнее проверить связь между продажей, возвратом и корректировкой. Доступ к истории и правила синхронизации нужно согласовать до интеграции, а не после появления расхождений.

Вывод

Источник итогового счёта

VeriFactu касается следа операции: от продажи и оформления документа до сохранения в учёте. Важно, чтобы этот след не исчезал, когда продажу отменяют, возвращают или исправляют.

Начните с определения источника итогового счёта. Затем проверьте движение данных между кассой, CRM и учётом. Отдельно опишите сценарии изменения уже оформленной операции.

Если нужно разобрать текущий контур и роли систем, воспользуйтесь контактами для обсуждения схемы интеграции.

FAQ