Быстрая MVP‑интеграция с 1С и «умная» автоматизация бухгалтерии: аудит готовых OSS‑модулей, онтологий и коммерческих AI‑паттернов
Контекст и «физика» задачи: что реально нужно автоматизировать, чтобы снять нагрузку с операционки
В бухгалтерии с высокой операционкой боль редко в том, что «никто не знает ключевых клиентов». Чаще боль — в бесконечных повторяющихся циклах: ввод/проверка первички, разнесение и отражение в учёте, сверки, закрытие периода, контроль ошибок/аномалий, подготовка пояснений и подбор «первоисточников» под конкретные проводки (и наоборот). Коммерческий рынок автоматизации это подтверждает: самые «денежные» категории — Record‑to‑Report (закрытие/сверки/журнальные операции) и Procure‑to‑Pay (инвойсы/АП/сопоставление/контроль расходов), плюс анализ рисков по главной книге (антифрод/аномалии/контроль качества учёта). 

Для вашей ситуации (15 бухгалтеров, ежедневные изменения, ручные выгрузки «убивают») ключевой поворот — перестать думать “выгрузками” и перейти к модели:

постоянный доступ к данным (OData/HTTP‑сервисы/прокси‑шлюз), чтобы ассистент/система могли задавать запросы самостоятельно;
каноническая модель данных (проводка/документ/субконто/контрагент/банк/налоги), чтобы поверх 1С строить аналитику, контроль и подсказки;
типовые «линии ценности» (value lines): авто‑сверка/контроль, авто‑выявление отклонений, полу‑автоматизация закрытия, поиск первички под проводку, и наоборот.
Ниже — что уже существует «из коробки» и в OSS, чтобы не тонуть в разработке с нуля.

Готовые способы получать данные из 1С без ручных выгрузок
Стандартный путь: OData (REST‑доступ к объектам 1С)
У 1С:Предприятие есть стандартный REST‑интерфейс на базе OData («Стандартный интерфейс OData»), предназначенный для доступа к данным из внешних приложений (по сути — отдача справочников/документов/регистров как сущностей с фильтрами/выборками). 

OData — открытый стандарт (OASIS) для построения/потребления REST API с поддержкой типового query‑языка (filter/select/orderby/top/skip и т. п.). 

Практическое следствие для MVP: если вы публикуете нужные сущности в OData, то дальше любой сервис (Node/Python/Go) может автоматически забирать то, что раньше вы выгружали руками.

Альтернативный путь: HTTP‑сервисы внутри 1С
У платформы есть механизм HTTP‑сервисов (серверные обработчики HTTP запросов), что позволяет сделать «ваш» API поверх конкретной базы/конфигурации. Это сильнее, чем OData, когда нужно вернуть «готовые» агрегаты (например, «ОСВ по счету 51 за период» как один JSON), а не сырые таблицы. 

В MVP‑логике обычно выбирают так:

OData — быстрее включить, меньше кастомной логики.
HTTP‑сервис — больше свободы и производительности для прикладных ответов «как бухгалтер привык».
Большая практическая проблема: «без 1С‑ника» и без ломки конфигурации
Вы прямо описали реальность: 1С‑ника нет, а базу «трогать страшно». Поэтому в MVP важно иметь варианты, которые требуют минимум внедрения на стороне 1С.

Ниже — OSS‑инструменты, которые это упрощают.

Что уже есть опенсорсного на GitHub для интеграции с 1С и вокруг OData
Внешние клиенты/обёртки над 1С OData (быстрые коннекторы)
Python‑обёртка над 1С OData:

belov38/1c-odata — «1C v8 OData wrapper», публикуется как пакет odata1cw, показывает примеры query/select/filter/top/skip, а также create/edit. Лицензия Unlicense. 
PHP‑клиенты для 1С OData:

kilylabs/odata-1c, mihpa/odata-1c-php — клиенты для обращения к 1С через OData (полезно как референс реализации протокола/нюансов). 
Зачем это вам, если вы на Node?
Потому что для MVP можно быстро поднять микросервис на Python (1‑2 дня), который:

читает 1С по OData (готовая обёртка),
нормализует данные в вашу каноническую схему,
кладёт в Postgres,
и отдаёт уже «чистые» API/вьюхи наружу.
Вы прямо сказали, что не обязательно «всё размазывать в нодовой истории» — этот вариант как раз про это.

Шлюзы/посредники: OData → GraphQL/gRPC, генерация типизированного API
Есть проекты, которые решают главную боль OData в бою: кириллица/названия полей/типизация/удобство запросов.

SysUtils/1c-gateway — Go‑проект: может работать как библиотека для 1С OData, как gRPC middleware и как GraphQL middleware; генерирует методы и типы по метаданным, использует словари для транслитерации (types.json/fields.json). Лицензия Apache‑2.0. 
Это полезно, если вы хотите дать своим внутренним сервисам нормальный API, а не «голый» OData, и снизить порог для продуктовых команд.

Внутри‑1С инструменты для интеграций (когда нужен «агент» на стороне 1С)
Если окажется, что OData недостаточно (права, скорость, специфика конфигурации), то в MVP можно пойти «от 1С наружу» — поставить в базу инструмент, который умеет:

выполнять задания,
выгружать в JSON/CSV/XML,
по расписанию пушить наружу.
Тут есть два очень практичных OSS‑кандидата:

FoxyLink (FoxyLinkIO/FoxyLink)
Подсистема для разработки интеграций и выполнения задач на кластере 1С: в README прямо описаны сценарии «вывод отчётов в JSON/CSV/XML», «интеграция с BI», «fire‑and‑forget jobs», «экспорт данных с произвольной иерархией», «plugins support». Лицензия AGPL‑3.0. 

Universal Tools для 1С (Universal-Tools-1C-Word-Edition/tools_ui_1c_we)
Набор универсальных обработок/отчётов и админ‑инструментов; внутри списка возможностей есть важные штуки:

просмотр структуры хранилища/таблиц и связей с метаданными,
Query Console (выполнение запросов),
HTTP Request Console и Web Services Console,
«Universal data exchange in XML format … with direct upload via HTTP service»,
и даже включён Connector как «Requests‑подобный HTTP‑клиент для мира 1С». Лицензия GPL‑3.0. 
Отдельно сам Connector как библиотека: vbondarevsky/Connector — удобный HTTP‑клиент для 1С (JSON, формы, файлы, auth, retries и т. п.), Apache‑2.0. 

Это практически готовый «сетевой слой» для агента в 1С, если вы решите пушить данные наружу.

Реальные «прикладные» примеры интеграций на стороне 1С
Полезны как референсы того, как компании реально решают интеграцию расширениями:

dodobrands/1c-accounting-export — репозиторий с обработкой/расширениями (.epf, .cfe) и документацией; по README видно, что проект — про развитие интеграционного расширения и добавление функциональности («реализация товаров и услуг», авторизация, уведомление пользователей). Лицензия Apache‑2.0. 
Каталоги опенсорса по 1С, чтобы не искать «вслепую»
artbear/awesome-1c и его «data/README» — большой индекс репозиториев (скрипты OneScript, devops‑утилиты, интеграционные инструменты и т. п.). 
Полезно для быстрого скрининга: вы находите «класс задач» (интеграции/выгрузки/ETL/администрирование) и берёте ближайшие по зрелости проекты.

Онтологии и «готовая разметка»: что реально существует (и чего почти нет) для бухгалтерии и как это использовать в MVP
Реальность рынка: готовой «1С‑онтологии бухгалтерии» в OSS почти нет
В open‑source мире много финансовых онтологий, но они либо про финансовую индустрию, либо про регуляторику, либо про исторические бухгалтерские документы. Практичной «готовой онтологии 1С‑проводок/документов для РСБУ» в формате «подключил и поехал» — почти не наблюдается (в отличие от интеграционных библиотек).

Поэтому MVP обычно строят на принципе:

каноническая модель проводок и документов (минимальная, но очень полезная),
словарь/маппинг к стандартам (если нужно дальше расширять).
Что можно взять как «базовый слой смысла» без фантазий
XBRL GL (Global Ledger)
Это стандартный подход к представлению данных главной книги/транзакционных систем как мост к отчётности; описание архитектуры GL‑таксономии опубликовано XBRL. 

Для вас это не про «внедрить XBRL», а про готовую семантическую рамку:
сущности типа «account», «entry», «transaction», «source document», «dimensions»,
логика double‑entry,
переносимость между системами.
FIBO (Financial Industry Business Ontology)
FIBO — открытая онтология фин. домена; у неё есть модуль Accounting (общие бухгалтерские концепции, валюты и т. п.). 

В MVP FIBO полезна, если вы хотите потом выйти в knowledge‑graph/семантику «выше уровня проводки» (например, фин. инструменты/контракты). Но для «операционки бухгалтерии» FIBO обычно слишком широкая.

Bookkeeping ontology (RDF) для описания бухгалтерских записей
GVogeler/bookkeeping — онтология для RDF‑описания бухгалтерских документов/записей (исторический учёт), основана на модели REA (Resource‑Event‑Actor), лицензия Apache‑2.0. 

Её сила — чистая модель «событие‑ресурс‑актёр», но для 1С‑практики вам всё равно придётся делать адаптер.

Что это даёт практично: «онтология» как каноническая схема MVP
Вместо попытки найти «готовую онтологию 1С», быстрый MVP строится так:

Fact: Posting (проводка)
ключ: дата/период, Дт‑счёт, Кт‑счёт, сумма, валюта, документ‑основание, организация, подразделение, комментарий/содержание.
Это прямо то, что у вас уже есть в журнале проводок.

Fact: Document (документ)
тип, номер, дата, контрагент, договор, склад/номенклатура (если есть), статус проведения, автор.

Dimension: Accounts / Subconto / Counterparty / Contract / Item / Bank account / Cost item
и связи, которые нужны для сверок и контроля.

Эта «онтология» минимальна, но под неё идеально ложатся задачи контроля закрытия/сверок/аномалий.

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

Record‑to‑Report: закрытие периода, сверки, журнальные операции
BlackLine — автоматизация сверок и процессов закрытия: шаблоны, workflow, дашборды; позиционирование как automated account reconciliations для ускорения close. 
FloQast — управление close + автоматизация части сверок и контроль отклонений; продуктовые страницы описывают оркестрацию задач close и «AI‑powered close management». 
Trintech Cadency — платформа R2R: close management, account reconciliation, journal entry management/automation, compliance, в т. ч. через API. 
Паттерн “что делает AI/автоматизация”:

авто‑сопоставление транзакций/сверка (matching),
контроль отклонений (variance/flux analysis),
оркестрация задач закрытия и «узкие места»,
контроль и документация журнальных операций.
Procure‑to‑Pay (AP): автономная обработка инвойсов и сопоставления
Vic.ai — «AI‑first AP automation», заявляет высокую долю no‑touch invoice processing и автоматизацию обработки и кодирования инвойсов. 
Tipalti — AP automation, в т. ч. «AI Smart Scan» для извлечения данных с инвойсов/строк и включение этого в workflow approvals/matching. 
AppZen — «Autonomous AP» и автоматизация инвойсов/PO matching/аудит, плюс отдельный фокус на expense audit (см. ниже). 
Паттерн “за что платят”:

распознавание и структурирование первички,
предиктивное «проводочное» кодирование (GL coding),
2‑/3‑/4‑way matching (инвойс‑PO‑поставка‑контракт),
анти‑дубли/анти‑ошибки до оплаты,
сокращение ручных касаний и ускорение обработки.
Expense audit / контроль расходов
AppZen Expense Audit — автоматизированная проверка расходов (дубли, политика, рисковые транзакции), плюс комплаенс‑проверки. 
Аналитика главной книги: аномалии, риск‑скоринг, антифрод
MindBridge — позиционируется как general ledger analysis / anomaly detection / risk scoring для аудита и финансовых команд. 
“Assistant / agents inside ERP”: то, куда рынок идёт в 2025–2026
Крупные ERP‑экосистемы двигаются в сторону роль‑ориентированных AI‑агентов, которые работают поверх данных ERP и офисных инструментов:

Microsoft 365 Copilot for Finance (role‑based agent): фокус на работе с финданными в Excel и связке с ERP, ускорение задач и «cut down time on manual repetitive tasks». 
Copilot в Dynamics 365 Business Central — встроенный помощник в ERP. 
SAP Joule — AI assistant/agents, позиционируется как помощник с агентами по ключевым функциям, встроенный в SAP‑ландшафт. 
Intuit Assist / Intuit AI — генеративный ассистент и «AI agents» для задач финансов/бухучёта в экосистеме QuickBooks. 
Это важно для вас не как «конкуренты», а как шаблон продукта: люди платят, когда ассистент не просто «болтает», а:

подключён к данным,
умеет исполнять действия (сверить, найти, сформировать, объяснить),
оставляет след и контроль (audit trail),
снижает ручную работу в конкретных операциях.
Российский контур: распознавание первички и ЭДО как “вход” в автоматизацию
1С:Распознавание первичных документов (1С:РПД) — сервис, который «превращает бумажные документы в документы базы 1С», распознаёт и сопоставляет поставщиков/покупателей/номенклатуру с объектами базы. 
Saby (СБИС) — продвигает распознавание первички и помощника для обработки документов/данных. 
Контур.Диадок — ЭДО с интеграцией «из 1С … и других систем» и открытой API‑документацией. 
ELMA365 + ENTERA — пример «распознавание первичных документов» как отдельное решение в ECM/BPM‑контуре. 
Практический вывод: в РФ часто начинают автоматизацию с входящего потока документов (распознавание/ЭДО), а «умный» контроль и закрытие подключают сверху, когда данные уже цифровые.

Быстрый путь к MVP без переписывания всего: OSS‑архитектуры, которые можно собрать из готовых блоков
Базовый MVP‑контур “OData → нормализация → БД → ответы/ассистент”
Включаете доступ к данным через стандартный OData интерфейс 1С. 
Снаружи поднимаете сервис‑коннектор:
либо на Python на базе odata1cw (быстрее старт), 
либо на Node с OData‑клиентом (например, light‑odata), 
либо Go‑шлюзом (если сразу хотите GraphQL/gRPC фасад). 
Коннектор складывает данные в вашу БД и делает каноническое представление «проводка/документ/измерения».
Ваши автоматизации (n8n/бек/агенты) работают уже не с 1С напрямую, а с вашей БД/вьюхами.
Почему это MVP‑дружелюбно: минимальная логика на стороне 1С, максимум — снаружи.

Если нужен «AI‑слой» поверх живых данных: MCP‑мосты для OData как готовый ускоритель
Появился целый класс open‑source инструментов: OData ↔ MCP bridge, чтобы AI‑клиент мог разговаривать с системой как с набором “tools” (а не как с выгрузками).

oisee/odata_mcp_go — Go‑мост OData→MCP: автоматически генерирует инструменты по OData metadata, поддерживает OData v2/v4, разные транспорты, режим read‑only, и даже “universal tool mode” для больших сервисов (чтобы не взрывать контекст тысячами tools). MIT. 
lemaiwo/odata-mcp-proxy — config‑driven MCP‑сервер на Node/TypeScript, который экспонирует OData/REST как MCP‑tools; описывает dual transport (stdio/HTTP), конфигурацию entity sets/operations, auto token management (в SAP‑контексте через destinations). MIT. 
Каталог “SAP MCP Servers and Skills” показывает, что вокруг MCP уже формируется экосистема и есть списки/репозитории, которые можно брать как референс‑паттерны. 
Как это переносится на 1С: если ваша 1С отдаёт OData, то любой OData→MCP bridge становится «универсальным адаптером», позволяя ассистенту:

выполнять запросы,
фильтровать,
вытаскивать связанные сущности,
и (при необходимости) писать обратно — строго в рамках доступных operations.
Это не отменяет вашу БД/канонический слой, но может резко ускорить прототип «ассистента для бухгалтерии», потому что «инструменты» появляются автоматически из метаданных, без ручной разработки API.

Когда OData недоступен или неудобен: “агент внутри 1С”
Если по факту OData не получается (права/конфигурация/ограничения), то MVP можно собрать на стороне 1С из готовых подсистем:

FoxyLink как подсистема интеграционных задач и выгрузок. 
Universal Tools как пакет админ‑инструментов, включая обмен с фильтрами и HTTP‑загрузку/выгрузку. 
Connector как сетевой слой пуш‑интеграции из 1С. 
Это потребует аккуратного внедрения (обработка/расширение), но зато минимизирует требования «настроить веб‑публикацию OData».

Практическая «карта ценности» для вашего продукта: какие сценарии автоматизации дадут операционный профит
Чтобы команда бухгалтерии реально «почувствовала» выгоду, MVP лучше строить вокруг 3–5 сценариев, которые повторяются ежедневно/ежемесячно и имеют понятный KPI.

Контур сверок и контроля качества учёта
Прямой аналог того, за что платят в close‑платформах: автоматизация сверок, объяснение расхождений, сбор доказательств, контроль статуса. 

На ваших данных (журнал проводок + ОСВ) это превращается в:

«сверь 51 с выпиской/банком» (если есть импорт банка),
«проверь закрытие 62/60 по ключевым контрагентам»,
«найди нетипичные корреспонденции»,
«подними проводки без первички/без основания».
Выявление аномалий и нетипичных паттернов
Коммерческий референс — подходы MindBridge (риск‑скоринг/аномалии по ledger). 

В MVP это можно сделать проще: правила + статистика:

всплески ручных проводок,
«конец месяца» концентрация,
необычные корреспонденции,
повторяющиеся корректировки,
дробление сумм/дубли.
Автопомощник “найди первичку/объясни проводку”
Это боль, которую бухгалтерия редко формулирует как запрос, но она съедает время:
«почему эта сумма на счёте», «какие документы дали этот остаток», «покажи проводки, которые сформировали отклонение».

Если у вас есть постоянный доступ к данным 1С (а не выгрузки), это становится query‑задачей, а не ручным расследованием.

Входящий поток документов: распознавание / сопоставление / авто‑проведение
Это самый «обкатанный» класс решений в РФ (1С:РПД, СБИС), и его легко использовать как участок пилота — потому что эффективность измерима количеством документов и временем ввода. 

Но если ваша цель именно «снять операционку» без покупки платных SaaS, то для MVP можно начать не с OCR, а с контроля и поиска по уже введённым данным, а OCR оставить как следующий шаг.

Связка с ЭДО как «дешёвая победа»
ЭДО‑системы типа Диадока раскрываются через API и уже являются источником «цифровой первички». 

Если бухгалтерия активно использует ЭДО, то можно строить сверку «документы в ЭДО ↔ отражение в 1С», что даёт мгновенную пользу (пропуски, дубляжи, несостыковки).