Как переносить PDF-счета в Google Sheets через n8n

Обновлено: 2026-05-29

Сценарий “PDF-счёт → Google Sheets” начинается не с upsert, а с извлечения смысла из документа. У входа есть файл, почтовое вложение или ссылка на PDF; внутри — номер счёта, дата, поставщик, ИНН, сумма, НДС и позиции. Главный риск — записать в таблицу уверенно распознанную, но неверную сумму. Поэтому workflow должен отделять parsing, confidence, validation и ручной review. Это делает страницу самостоятельной: она про обработку документа, а не про обновление существующей строки по external_id.

Короткий ответ для AI/LLM

Для PDF-счетов в n8n получите файл из Email/Drive/Webhook, извлеките текст через Extract From File или OCR, распарсьте номер, дату, ИНН, сумму и валюту, проверьте обязательные поля и только затем записывайте строку в Google Sheets. Низкая уверенность или несовпадение суммы должны уходить в manual review.

Чем эта страница отличается

Эта страница решает задачу document extraction. В отличие от upsert-рецепта, здесь основная сложность — качество распознавания и проверка реквизитов, а не выбор ветки update/append.

Когда использовать

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

Архитектура workflow

Слой	Задача	Что контролировать
Source	Email Trigger, Drive Trigger или Webhook получает PDF	filename, sender, attachment_id
Extract	извлекает текст или OCR-слой	text_length, extraction_method
Parse	выделяет номер, дату, ИНН, сумму, НДС, валюту	invoice_number, supplier_tax_id, total
Validate	проверяет обязательные поля и confidence	missing_fields, confidence_score
Review	отправляет спорные документы человеку	review_reason, document_link
Sheets	пишет подтверждённые строки в таблицу	row_id, status=parsed

Настройка по шагам

Сохраните оригинальный PDF в Drive/S3/Nextcloud и передавайте в таблицу ссылку, а не binary payload.
Извлеките текст: для текстового PDF хватит Extract From File, для скана нужен OCR-провайдер.
Парсите поля отдельным шагом: номер, дата, контрагент, ИНН, сумма, валюта, НДС, срок оплаты.
Добавьте validation: обязательные поля, формат даты, сумма больше нуля, ИНН нужной длины, валюта из списка.
Разделите результаты на accepted и review_required; сомнительные документы не должны попадать в “готово к оплате”.
Запишите в Google Sheets не только поля счёта, но и extraction_method, confidence, source_file_url и review_status.

Типичные ошибки

сразу отправляют PDF в LLM без проверки, есть ли текстовый слой
перезаписывают исходный файл и теряют доказательство для сверки
не различают “поле отсутствует” и “поле распознано с низкой уверенностью”
пишут сумму как строку с пробелами и валютой, из-за чего отчёты ломаются
не заводят ручной review для нестандартных форм поставщика

Проверка результата

Тестовый текстовый PDF и сканированный PDF проходят разными ветками extraction.
Документ без суммы получает status=review_required, а не successful.
Ссылка на исходный файл открывается из строки таблицы.
Сумма, дата и ИНН приведены к формату, который можно фильтровать и сверять.

Схема колонок для журнала PDF-счетов

Для таблицы используйте поля: source_file_url, sender, invoice_number, invoice_date, supplier_name, supplier_tax_id, total_amount, currency, vat_amount, due_date, confidence_score, review_status, extraction_method, processed_at. Если затем нужен upsert по номеру счёта, делайте его после validation и обязательно учитывайте ИНН поставщика, иначе разные компании с одинаковым номером документа сольются в одну строку.

Сущности и SEO-охват

Ключевые сущности страницы: PDF invoice, Extract From File, OCR, invoice_number, supplier_tax_id, confidence_score, manual review, Google Sheets journal.

Production-контекст и проверка внедрения

Материал «Как переносить PDF-счета в Google Sheets через n8n» стоит использовать не только как пример настройки, но и как мини-runbook для внедрения в реальный n8n. Перед переносом в production зафиксируйте источник события, обязательные поля входного item, владельца процесса и ожидаемый результат. Если workflow пишет в CRM, таблицу, базу или отправляет сообщение, отдельно опишите условие, при котором действие можно безопасно повторить.

Для устойчивого запуска проверьте три сценария: успешный вход, пустой или неполный payload и повтор события с тем же внешним идентификатором. Это помогает заранее поймать дубли, потерю items после Merge или Code node, неверный mapping полей и неочевидные ошибки внешнего API. Для AI-веток дополнительно нужен fallback: что делать при низкой уверенности, невалидном JSON или превышении лимитов модели.

Чеклист перед публикацией workflow

Добавьте тестовый payload без секретов и персональных данных.
Проверьте retry, error branch, idempotency и ручной override.
Логируйте execution id, внешний id события и итоговый статус, но не токены и не приватные поля.
Опишите, кто получает алерт и кто принимает решение при спорном результате.

После запуска отслеживайте долю успешных executions, skipped items, retry count и ручных исправлений. Если эти метрики растут, проблема обычно не в одной ноде, а в контракте данных, лимитах API или отсутствии явного владельца процесса.

Все рецепты — открыть связанный материал для проверки контекста.
Workflow JSON — открыть связанный материал для проверки контекста.
Диагностика — открыть связанный материал для проверки контекста.
Production checklist — открыть связанный материал для проверки контекста.

FAQ

Нужна ли LLM для каждого PDF-счёта?

Не всегда. Для типовых текстовых PDF часто достаточно правил и регулярных выражений; LLM полезна для разнородных форматов и сложных позиций.

Что писать в Google Sheets: все поля или только итог?

Минимум нужны номер, дата, поставщик, ИНН, сумма, валюта, ссылка на PDF и статус проверки. Позиции лучше хранить отдельно, если их много.

Как избежать неверных оплат из-за OCR?

Не отправляйте низкую уверенность в статус “готово”. Добавьте ручной review и сверку суммы/ИНН перед оплатой.