Валидация реквизитов перед загрузкой в учетную систему: правила

Зачем бухгалтерии проверять данные до загрузки

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

Проблемы особенно заметны, когда реквизиты вытаскивают из писем и вложений. В письмах их часто копируют вручную, в PDF документ может быть «картинкой», а в скане мешают мелкий шрифт и печати. Даже хорошее распознавание путает похожие символы (0 и O, 1 и I), теряет пробелы в IBAN или «съедает» запятую в сумме.

Цена таких ошибок почти всегда высокая и обычно срочная:

• неверный IBAN или БИК приводит к возврату платежа или задержке оплаты
• ошибка в БИН/ИИН мешает идентификации контрагента и сверкам
• неверные сумма или НДС искажают налоговый учет и отчетность
• неправильная дата документа уводит операцию в другой период
• расхождение между счетом и актом затягивает закрытие месяца

Чаще всего процесс ломается в трех местах: при ручном вводе (усталость и спешка), при копировании из письма (лишний пробел или символ) и при распознавании (неверно выделили поля или перепутали формат). Поэтому проверка реквизитов до загрузки работает как фильтр: она ловит ошибки до того, как они станут реальной операцией.

Приемлемое качество входных данных довольно простое: обязательные поля заполнены, форматы соответствуют правилам (длина, символы, контрольные проверки), суммы сходятся между документами и итогами, даты попадают в нужный период и не противоречат друг другу. Если хотя бы одно условие не выполняется, документ лучше отправить на уточнение, чем «поправить на глаз».

Откуда берутся реквизиты: письма и вложения

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

Типовые источники:

• тело письма (сумма к оплате, срок, комментарии по закрывающим)
• подпись отправителя (название компании, телефон, иногда БИН и адрес)
• PDF со счетом или актом (основные реквизиты, суммы, НДС, номера)
• сканы и фото документов (часто без структурированных полей)
• Excel/CSV (реестры, расшифровки, позиции)

Обычно извлекают: поставщика и его БИН/ИИН, номер и дату счета, номер и дату акта/накладной, номер договора или заявки, IBAN и БИК, сумму, НДС, назначение платежа и условия оплаты. Полезно сразу разделять данные для оплаты (банковские реквизиты и сумма к оплате) и данные для учета (документ-основание, период, ставка НДС).

Не каждое вложение - первичный документ. Перед обработкой быстро проверьте, что файл похож на финальную форму: есть номер и дата (а не «проект»), указан поставщик и получатель, есть итоговая сумма и НДС (если применимо), и сам документ выглядит как счет/акт/накладная, а не письмо, сохраненное в PDF.

Чтобы потом не разбирать спорные случаи, фиксируйте происхождение полей: из какого письма и какого вложения взято, кто отправитель, когда получено, и какая версия файла использована (например, «Счет_123.pdf» и «Счет_123_исправл.pdf»). Это экономит время, когда поставщик присылает исправление или в переписке меняется сумма.

Минимальный набор реквизитов и что считать обязательным

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

Обязательными обычно считают идентификаторы контрагента и реквизиты документа. Для контрагента это БИН или ИИН и официальное наименование. Адрес нужен только если он обязателен по вашей форме первички или используется в договорной части.

С банковскими реквизитами заранее определите правило: что берете из документа, а что из справочника контрагентов. В документе чаще всего встречаются IBAN и БИК, иногда банк и КБЕ. Если в письме или скане указан IBAN, но он не совпадает со справочником, это повод поставить документ на уточнение, а не угадывать.

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

По суммам фиксируйте не только «итого», но и НДС, валюту и сумму к оплате (если она отличается из-за удержаний или аванса). Если НДС не выделен, это должно быть явным значением (например, 0) или отдельной отметкой.

Также заранее определите служебные поля, без которых документ нельзя провести в вашей компании: подразделение, статья затрат, проект. Счет может быть корректным по БИН и IBAN, но без проекта его все равно не разнести по бюджету.

Короткое правило: обязательным считается то, без чего документ нельзя провести однозначно и без догадок.

Правила проверки реквизитов: формат, длина, контроль

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

Единый формат перед проверками

Начните с нормализации: уберите лишние пробелы, приведите кавычки к одному виду, унифицируйте регистр латинских букв (например, все в верхний), приведите даты к одному разделителю. Для реквизитов это критично: IBAN часто приходит с пробелами, БИК могут написать с дефисом, а в наименовании встречаются разные кавычки и сокращения.

После этого включайте «жесткие» проверки:

• БИН/ИИН: только цифры, длина 12, без пробелов и знаков.
• IBAN: латинские буквы и цифры, без пробелов; длина по стране (для KZ обычно 20 символов).
• БИК: проверка по допустимому формату, который принят у вас (часто 8 или 11 символов).
• Дата: один формат на входе (например, ДД.ММ.ГГГГ), без «смешанных» разделителей.
• Наименование: без двойных пробелов, с единым написанием правовой формы (ТОО, АО и т.п.).

Контрольные проверки и сверка со справочниками

Где возможно, добавляйте контрольные алгоритмы. Для IBAN полезна стандартная проверка по модулю 97 - она хорошо отсекает опечатки внутри номера. Для БИН/ИИН минимумом будет проверка длины и отсеивание явно «подозрительных» значений (например, все нули).

Дальше обязательно сопоставляйте данные с карточкой контрагента: БИН/ИИН должен совпадать с тем, что уже заведено, а IBAN должен принадлежать этому же контрагенту. Если БИН совпал, а IBAN новый, лучше отправить документ на ручную проверку, а не создавать новую карточку автоматически.

Пример: в письме поставщик пишет IBAN с пробелами, а во вложении - без пробелов, но одна цифра отличается. Нормализация сделает оба варианта одинаковыми по виду, а контроль IBAN быстро покажет, где ошибка.

Проверка сумм и НДС

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

Арифметика и логика

Начните с простого: сумма по строкам должна сходиться с итогами. Если в документе есть «без НДС» и «НДС», итог должен равняться их сумме. Если НДС не применяется, итог должен совпадать с суммой без НДС, а поле НДС должно быть пустым или равно нулю.

Если в документе есть позиции, проверьте строки: количество x цена = сумма строки. Затем суммируйте строки и сравнивайте с итогом. Разница в 1-2 тыйын из-за округления возможна, но она должна укладываться в заранее заданный допуск.

Валюта, округление и ставка

В одном документе должна быть одна валюта и единый формат дробной части (обычно 2 знака). Суммы с 3-4 знаками после запятой - повод пересчитать по вашим правилам округления и зафиксировать отклонение.

По НДС проверьте три вещи: ставка соответствует договору и типу операции, НДС рассчитан от правильной базы (с учетом скидок), а итог «к оплате» логично согласуется с авансом или частичной оплатой, если они есть.

Пример: счет на 1 120 000 тг, где база 1 000 000 тг и НДС 120 000 тг. Если извлечение из PDF дало НДС 12 000 тг из-за пропущенного нуля, арифметика поймает это сразу.

Риск-флаги

Отмечайте документ как риск, если сумма неожиданно «слишком большая» для контрагента, появляются отрицательные значения без объяснения (возврат, корректировка), повторяются одинаковые строки, или итог подозрительно совпадает с другим документом за тот же период.

Проверка дат и периодов

Дата в первичке влияет на НДС, закрытие месяца и период в учете. Поэтому сначала приводите даты к единому виду, а затем проверяйте логику.

В письмах и вложениях встречаются «дд.мм.гггг», «дд/мм/гг», «10 января 2026», а иногда двусмысленное «01.02.2026». Для бухгалтерии безопаснее хранить исходное значение и рядом - распознанную дату. Если есть риск путаницы день-месяц, ставьте статус «нужна проверка».

Логика дат

Смотрите на последовательность событий. Часто дата документа не должна быть позже даты письма, которым он пришел, но бывают исключения: пересылка закрывающих за прошлый период, дубль счета, письмо с архивом. Поэтому правило лучше формулировать так: «позже письма допустимо только при понятном объяснении и подтверждении».

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

Периоды, оплата и закрытие месяца

Если документ относится к закрытому периоду, загрузку лучше блокировать и отправлять на ручное решение (корректировка, сторно, допсоглашение).

Практичный набор проверок:

• дата документа попадает в допустимый месяц (период не закрыт и дата не слишком далеко в будущем)
• срок оплаты не раньше даты счета
• дата поставки (если указана) не конфликтует с датой акта без причины
• в комплекте документов по одной поставке даты не противоречат друг другу

Пример: поставщик прислал акт датой 31.03, а письмо пришло 02.04. Это допустимо, но документ не должен уйти в уже закрытый март без согласования.

Пошаговый процесс проверки перед загрузкой

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

Дальше - извлечение полей и нормализация: суммы в одной валюте и с одинаковым количеством знаков, даты в одном формате, пробелы и лишние символы в БИН/ИИН и IBAN удалены, названия организаций без случайных переносов строк.

Удобная схема для потока документов:

• определить тип документа и набор ожидаемых полей
• извлечь поля из письма и вложений, сразу нормализовать
• проверить обязательные поля и остановиться при критических ошибках
• сверить со справочниками (контрагент, договор, банковские реквизиты) и проверить суммы и даты
• присвоить статус и сохранить причину, если нужен человек

Сверки лучше делать по принципу «сначала простое, потом сложное»: совпадает ли БИН с карточкой контрагента, привязан ли договор, корректен ли IBAN и БИК, сходятся ли итог и НДС, укладываются ли даты в нужный период.

В конце у документа должен быть понятный статус: «готово к загрузке», «нужна проверка» или «отклонено». Если документ отклонен, причина должна быть конкретной: «IBAN не проходит контроль», «дата акта раньше даты договора», «нет номера счета». Эти причины потом помогают улучшать правила и снижать долю ручной работы.

Частые ошибки и ловушки при извлечении из писем

В одном треде могут быть счет, акт, допсоглашение и переписка менеджеров. Если система или человек подхватывает данные «как нашли», легко смешать реквизиты разных документов: номер счета из одного файла, сумму из другого, дату из текста письма.

Отдельная ловушка - реквизиты в подписи. Там нередко остаются старые банковские данные, а во вложении уже новые. Если не задать приоритет источников, получится «правдоподобный» IBAN или БИК, который похож на настоящий, но относится не к тому документу.

Еще один частый кейс - дубли. Один и тот же счет приходит несколько раз: «черновик», потом «исправленный», потом «пересылаю еще раз, тут печать». Вложения могут отличаться одной страницей или одной строкой суммы. Без контроля версий легко загрузить дважды или принять устаревший файл.

Даже при хорошем OCR встречаются ошибки: 0 и O, 1 и I, потерянная цифра в БИН или IBAN, лишний пробел внутри номера. Поэтому проверки должны ловить не только «пусто», но и «похоже, но неверно».

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

Короткий чек-лист перед загрузкой в учетную систему

Перед тем как нажать «Загрузить», сделайте быстрый контроль. Он занимает пару минут, но часто экономит часы разборов и исправлений.

• Контрагент опознан: БИН/ИИН заполнен и совпадает с тем, что уже есть в базе.
• Банковские реквизиты чистые: IBAN и БИК без пробелов, лишних символов и переносов строки.
• Документ можно идентифицировать: есть номер и дата, без очевидных странностей (например, дата в будущем или номер из одних нулей).
• Суммы сходятся: итог, НДС и сумма к оплате не противоречат друг другу и простой арифметике.
• Даты не ломают учет: период не закрыт, а цепочка выглядит логично (счет -> оплата -> акт/накладная).

Отдельно проверьте дубли. Если совпадают контрагент, номер, дата и сумма, лучше остановиться и уточнить, не пришла ли исправленная версия.

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

Пример сценария: обработка счета и акта от поставщика

Поставщик прислал письмо: во вложениях PDF со счетом и PDF с актом. В тексте письма он написал сумму и срок оплаты, а в подписи у менеджера есть IBAN и БИК. Задача - проверить данные так, чтобы бухгалтер видел только надежные значения.

Источники данных имеют разный вес. Реквизиты и суммы берите из первичных документов во вложениях (счет, акт). Текст письма и подпись используйте как подсказку для поиска или для ручной проверки, но не как «истину».

Дальше извлеките и проверьте ключевые поля: БИН/ИИН (только цифры, длина 12, совпадает между счетом и актом), IBAN и БИК (формат, длина, контроль IBAN, совпадение между документами), суммы (итого, без НДС, НДС, логика «итого = без НДС + НДС»), даты (дата счета, дата акта, период оказания услуг).

Типичный конфликт: в акте дата 31.01, а в счете 05.02. Если акт закрывает январь, а счет выставлен в феврале, это может быть нормой, но тогда правило должно быть явным: период в акте подтверждает январь, а счет может быть позже. Если же период в акте указан как февраль, а дата январская, ставьте «нужна ручная проверка».

Результат должен быть простым: либо «готово к загрузке» с заполненными полями и отметками проверок, либо «стоп» с причиной (не совпал БИН, не сходится НДС, конфликт периода). Тогда понятно, что исправлять и где первоисточник.

Практические следующие шаги и где это лучше запускать

Зафиксируйте правила в коротком регламенте и разделите их на две группы: критичные (без них документ нельзя загрузить) и уточняемые (можно принять в работу, но нужно подтверждение). Затем договоритесь о единых статусах и причинах отклонений, чтобы видеть качество входящих документов и повторяющиеся ошибки у поставщиков.

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

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

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