Автоматизация бухгалтерии с ИИ на VPS

MAATRIX

Если в бухгалтерии на вас — десятки счетов и чеков в месяц, ручной перенос сумм в таблицы и постоянный страх пропустить срок сдачи отчёта, львиную долю этой рутины можно снять с себя автоматизацией. Не заменой бухгалтера искусственным интеллектом, а конвейером: n8n на своём сервере разбирает входящие документы, вытаскивает из них данные и напоминает о дедлайнах, а человек проверяет результат и принимает решения там, где нужна квалификация. Ниже — рабочие сценарии, которые можно повторить, и честный разговор о том, где граница между «ИИ помогает» и «ИИ ошибается».

Что реально можно автоматизировать, а что нет

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

Хорошо поддаётся автоматизации — механическая обработка объёма:

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

Плохо поддаётся или не должно автоматизироваться без контроля:

• Итоговая классификация операций для налогового учёта и выбор проводок.
• Трактовка неоднозначных операций с точки зрения налогового законодательства.
• Подготовка и подписание отчётности, отправка в контролирующие органы.
• Любые решения, где ошибка стоит штрафа или доначисления.

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

Архитектура: n8n + OCR + LLM на своём сервере

Базовый стек из трёх компонентов, которые разворачиваются на одном VPS:

1. n8n — оркестратор: принимает документы (почта, Telegram, папка на диске, веб-форма), прогоняет их через цепочку узлов, пишет результат в таблицу или систему учёта.
2. OCR-слой — распознавание текста со сканов и фото. Для машинописных документов среднего качества обычно достаточно Tesseract; для сложных сканов и фото с телефона лучше отрабатывает vision-модель через LLM (она же может сразу извлекать структуру, минуя отдельный OCR-шаг).
3. LLM для извлечения и категоризации — либо облачная модель через API-прокси, либо локальная модель через Ollama/vLLM, если документы чувствительные и не должны покидать периметр.

Минимальный docker-compose для связки n8n + Postgres (под хранение состояния и логов обработки):

version: "3.8"
services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change_me
      POSTGRES_DB: n8n
    volumes:
      - ./pg-data:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change_me
      N8N_BASIC_AUTH_ACTIVE: "true"
      N8N_BASIC_AUTH_USER: admin
      N8N_BASIC_AUTH_PASSWORD: change_me
      GENERIC_TIMEZONE: Europe/Moscow
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on:
      - postgres

Подробный пошаговый разбор установки — в статье про установку n8n на VPS, а связку n8n с ИИ-агентами и подбор ресурсов под нагрузку разбирают статьи про n8n с AI-агентами и про то, сколько RAM нужно для n8n. Для старта с обработкой десятков документов в день хватает 4 vCPU / 8 ГБ RAM, если LLM вызывается по API; если планируете локальную модель для чувствительных документов — закладывайте отдельный сервер под инференс, это отдельная статья расходов.

Сценарий 1: распознавание и категоризация счетов и чеков

Типовой воркфлоу в n8n выглядит так:

1. Триггер — узел Email Trigger (IMAP) слушает ящик, куда контрагенты и сотрудники присылают счета, либо Telegram Trigger принимает фото чека прямо из чата.
2. Приём файла — вложение сохраняется во временное хранилище (узел Move Binary Data или запись в S3-совместимое хранилище на том же сервере).
3. Распознавание — HTTP Request к vision-модели с промптом на извлечение текста и полей одновременно, либо отдельный вызов Tesseract через Execute Command.
4. Категоризация — отдельный запрос к LLM с фиксированным списком статей расходов компании, чтобы модель не придумывала свои категории:

Ты помощник бухгалтера. Определи категорию траты СТРОГО из списка:
[Аренда, Транспорт, Канцелярия, Связь и интернет, Услуги подрядчиков,
Программное обеспечение, Реклама, Прочее].

Данные документа:
Контрагент: {{ $json.vendor }}
Назначение платежа: {{ $json.description }}
Сумма: {{ $json.amount }}

Верни только название категории из списка, без пояснений.

1. Запись результата — узел Google Sheets, Airtable или прямой HTTP-запрос к API системы учёта добавляет строку: дата, контрагент, сумма, категория, ссылка на исходный файл.
2. Контроль — если модель не уверена (пустое поле, сумма не распознана, категория не из списка) — документ падает в отдельную очередь «на ручную проверку», а не проходит автоматом.

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

Сценарий 2: извлечение данных из документов в структурированный вид

Для актов, накладных и многостраничных счетов важно не просто получить сумму, а разложить документ на структуру, которую можно проверить и загрузить дальше. Здесь помогает жёсткая схема вывода — просите модель вернуть JSON по фиксированной структуре и валидируйте его в n8n перед записью:

{
  "document_type": "invoice",
  "vendor_name": "ООО Ромашка",
  "vendor_inn": "7712345678",
  "invoice_number": "№142",
  "invoice_date": "2026-08-14",
  "due_date": "2026-08-28",
  "total_amount": 45600.00,
  "vat_amount": 7600.00,
  "currency": "RUB",
  "line_items": [
    {"description": "Услуги хостинга, август", "amount": 45600.00}
  ],
  "confidence": "high"
}

Поле confidence модель заполняет сама — если она сомневается в разборчивости скана или в трактовке суммы, отмечает low, и в n8n это становится условием для отдельной ветки (например, отправить файл человеку в Telegram с просьбой проверить). После JSON узел Function в n8n проверяет базовую консистентность: сумма НДС не больше общей суммы, дата в разумном диапазоне, ИНН — 10 или 12 цифр. Это дешёвая защита от галлюцинаций модели, которая ловит заметную часть ошибок ещё до того, как данные попадут в таблицу.

Готовые структурированные данные удобно выгружать не только в таблицы, но и через API — если у вас уже настроен пайплайн анализа документов, посмотрите статью про ИИ-анализ документов на сервере — многие узлы оттуда переиспользуются напрямую.

Сценарий 3: напоминания о сроках отчётности и платежей

Третий контур — не про документы, а про время. Здесь n8n работает как надёжный будильник, который не забывает и не устаёт:

• Cron-триггер раз в день проверяет таблицу с датами: сроки уплаты налогов и взносов, сдачи деклараций, оплаты счетов с приближающимся due_date из сценария 2.
• Условная логика — если до срока осталось 3 дня и платёж не отмечен как выполненный, узел отправляет уведомление в Telegram-чат бухгалтерии или на почту, с сокращающимся интервалом по мере приближения даты (за 7 дней, за 3 дня, за 1 день).
• Эскалация — если срок наступил, а статус не изменился, сообщение уходит не только исполнителю, но и руководителю — это тот случай, где лучше показаться навязчивым, чем пропустить дедлайн.

Такой воркфлоу не требует сложной модели — достаточно табличных данных и условий, LLM здесь опционален (например, для генерации человекочитаемого текста напоминания вместо сухого шаблона). Зато именно эта часть автоматизации обычно даёт самый быстрый и заметный эффект: пропущенные сроки — самая дорогая категория ошибок в бухгалтерии, и убрать человеческий фактор из «не забыть» проще всего.

Честная граница: чего ИИ не должен решать сам

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

• Модель не знает актуального налогового законодательства достоверно. Даже если она уверенно называет ставки и сроки, это не источник правды — проверяйте по официальным документам или у бухгалтера/налогового консультанта, особенно если что-то поменялось недавно.
• Распознавание не бывает стопроцентным. Плохой скан, рукописная правка на счёте, нестандартный формат документа — всё это повышает шанс ошибки. Отсюда обязательное поле confidence и очередь на ручную проверку из сценариев выше.
• Категоризация — это подсказка, а не проводка. Модель предлагает статью расходов для управленческого учёта; финальное отнесение операции для налогового учёта — решение бухгалтера, который видит контекст сделки целиком.
• Никаких автоматических отправок в контролирующие органы. Воркфлоу должен готовить черновик и данные для человека, а не подписывать и отправлять отчётность самостоятельно.

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

Частые вопросы