Обработка счетов и документов с AI: контроль вместо слепой автоматизации

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

Ниже — ответ на узкий implementation-вопрос: как спроектировать контролируемый AI-assisted workflow для счетов и документов. Он не заменяет broad commercial landing page AI-специалист в Армении. Scope внедрения находится в AI-автоматизации, а публичные proof artifacts — в разделе кейсов.

1. Начните с процесса и границы доказательств

Небезопасное сокращение выглядит так: PDF -> model -> accounting entry. В нём исчезает реальная работа: приём документа, контроль дублей, идентификация поставщика, налоговая и approval policy, исключения и подтверждение из system of record. Начните с одного bounded workflow — например, с подготовки review packet для входящего счёта. Не начинайте с обещания автономного posting или payment.

У каждого intake должен быть устойчивый идентификатор: tenant или юридическое лицо, source channel, время receipt, hash файла, version документа, retention policy и состояние процесса. Оригинальный файл хранится отдельно от производного текста и извлечённых полей. Повтор OCR или исправленный документ должен создавать новую version, а не незаметно менять evidence под уже подготовленным предложением.

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

• Какие типы документов и языки реально входят в scope?
• Какой источник authority для поставщика, purchase order, поставки, tax code и cost center?
• Какие решения deterministic, какие требует authorized reviewer, а какие должны останавливать workflow?
• Какой safe fallback сработает при недоступности source, integration или модели?

В workflow должны попадать только разрешённые данные. Вложения могут содержать банковские реквизиты, адреса, имена сотрудников и позиции заказа. Заранее определите, кто видит оригинал, какие поля могут попасть в extraction service, сколько живут производные данные и как reviewer находит исходное evidence. Полный на вид JSON не доказывает, что evidence разрешено, актуально или корректно.

2. Спроектируйте DOCS-7 как контролируемый workflow

DOCS-7 — reference sequence, которая создаёт reviewable document record. Она не зависит от provider: email, supplier portal, scanner и API требуют разных adapters, но control contract остаётся общим.

1. Receive source file вместе с receipt, hash, tenant и channel identity.
2. Classify document type и language, сохраняя состояние unknown.
3. Extract typed candidate fields вместе с source spans и явной uncertainty.
4. Match только с разрешёнными supplier, PO, goods-receipt или contract references.
5. Validate обязательные поля, арифметику, duplicate keys, policy и current version master data.
6. Review исключения и любое consequential решение по posting или payment у authorized owner.
7. Commit and read back идемпотентный draft либо approved record, затем проверить destination state и recovery owner.

Модель находится на третьем шаге. Она может предложить document type, номер счёта, даты, totals, currencies, supplier candidates и объяснение uncertainty. Она не должна решать, что поставщик валиден, выдумывать отсутствующий tax code, утверждать payment или считать визуальную галочку подтверждённой ERP-записью. Эти решения принадлежат deterministic services и людям.

{
  "documentId": "doc-2026-08-11-014",
  "tenantId": "entity-07",
  "sourceHash": "sha256:...",
  "documentVersion": 1,
  "proposal": {
    "invoiceNumber": { "value": "INV-4821", "evidence": ["page:1:region:12"], "uncertain": false },
    "total": { "value": "125000", "currency": "AMD", "evidence": ["page:1:region:37"], "uncertain": false },
    "supplierCandidate": { "value": "supplier-ref-unknown", "uncertain": true }
  },
  "state": "review_required"
}

Этот пример — extraction proposal, а не бухгалтерский документ. Принимающая система должна отклонять отсутствующее evidence, неверные types, неподдерживаемые currencies, stale mappings и любую попытку пропустить policy gate.

3. Сделайте интеграции явными контрактами

Большинство document-проектов ломается на boundaries, а не на распознавании текста. Source adapter должен отличать доставленный файл от пригодного документа. Document store сохраняет стабильную reference без широкого доступа. Master-data adapter возвращает versioned supplier или PO candidate, а не размытый факт. Accounting adapter должен поддерживать idempotency key и authoritative read-back.

Каждую границу полезно оформить как малый contract:

Особенно важны match rules. Модель может прочитать имя поставщика иначе, чем оно записано в master data. Это повод для deterministic lookup или review, а не разрешение создать нового vendor. Аналогично, арифметика totals проверяется deterministic только после определения document type, currency и convention округления. Сохраняйте rules и versions, которые дали каждый validation outcome.

Права integration должны быть минимальными. Первый pilot может создавать review task или accounting draft в sandbox вместо posting journals. Если destination write завершается timeout, запишите reconcile_required и спросите authoritative system до retry. Слепой replay может создать duplicate payable.

4. Определите проверки до live pilot

Один accuracy percentage не является acceptance criterion: он смешивает безобидную разницу форматирования и consequential error. Соберите acceptance set из representative documents: чистые digital PDF, сканы, multi-page invoices, credit notes, mixed languages, duplicate deliveries, отсутствующие PO, изменившиеся vendor details и документы, которые надо отвергнуть.

Оценивайте workflow по слоям:

• Field contract: types, required fields, evidence spans, currency и арифметика.
• Match contract: правильная entity boundary, candidate status, duplicate detection и current master data.
• Policy contract: rule version, thresholds, approver authority и expiry.
• Integration contract: idempotent destination request, read-back, reconciliation и audit trail.
• Operational contract: timeout, retry, dead-letter, pause switch, retention и named recovery owner.

Acceptance criteria должны быть наблюдаемыми. Например: у каждого committed draft есть source hash; у каждого critical extracted field есть allowed evidence reference; duplicate source не создаёт вторую destination record; неизвестный supplier или tax treatment приходит к reviewer; ambiguous write не повторяется без reconciliation; reviewer видит proposal, evidence, policy version и decision rationale.

require(document.hash && document.tenantId && document.version && source.receipt);
require(proposal.schemaValid && proposal.criticalEvidence && match.currentMasterData);
commit = policy.permits && reviewer.authorized && destination.readBack && recovery.owner;

В test set намеренно добавляйте failures. Размытый счёт не должен превращаться в правдоподобную сумму. Tenant mismatch должен fail closed. Старый PO нельзя принимать лишь потому, что его номер виден на странице. Timeout destination обязан пройти reconciliation path. Такие cases информативнее polished demo.

5. Эксплуатация, улучшение и метрики узкого workflow

Первый релиз — controlled pilot: одна entity, ограниченные document types, review-first state, named process owner и reversible destination action. До интерпретации новой системы зафиксируйте baseline ручного процесса. Полезно наблюдать preparation time, exception categories, correction causes, duplicate blocks, review age и reconciliation backlog; это operating signals, а не универсальные обещания ROI.

Разбирайте corrections по причинам. Повторяющийся missing PO может быть проблемой procurement process, а не extraction. Conflict supplier match может указывать на stale master data. Reviewer, который постоянно override-ит rule, мог обнаружить policy gap. Меняйте один contract за раз, version-ируйте его, replay acceptance set и расширяйте scope только после понимания нового поведения.

Правильный результат — не «AI сам обрабатывает счета». Это traceable process, в котором документ становится bounded proposal, policy и люди сохраняют authority, а system of record подтверждает итог. Чтобы обсудить контролируемый pilot document automation, подготовьте проектный бриф.