Парная сверка межфирменных остатков до консолидации
Как сопоставить требования и обязательства двух юридических лиц на согласованный срез, сохранить частичные совпадения и объяснить остаточные расхождения.
6 мин чтения·База знаний
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Перед консолидацией нужно выяснить, почему требование компании A к компании B отличается от встречного обязательства B перед A. Это сравнение двух самостоятельных учётных представлений, а не проверка копии одного набора событий. Разные локальные идентификаторы документов допустимы; равенство сумм без подтверждённой связи документов недостаточно.
Ниже предложен проектный контракт EDWH для торговой дебиторской и кредиторской задолженности внутри согласованного периметра группы. Алгоритм элиминации, трансляция зарубежных операций, займы и полный процесс консолидации вне рамок. Правила сопоставления и допуска расхождений не объявляются требованиями IFRS. Материал не описывает опыт автора или реализацию лаборатории.
Зерно входа - остаток одной позиции документа на дату отчёта в выбранной книге юридического лица и валюте документа. Ключ включает систему, юридическое лицо, книгу, документ и позицию; версия снимка хранится отдельно. Если источник даёт только агрегированный остаток по контрагенту, можно сверить этот уровень, но нельзя заявлять согласование отдельных документов.
Версионируемое отображение справочников связывает локального клиента или поставщика с юридическим лицом группы. Проверяют обратность: A указывает партнёра B, а B указывает партнёра A. Неизвестное или неоднозначное отображение блокирует автоматическое сопоставление. Канонический ключ пары упорядочивает два устойчивых ID, но сохраняет направление требования. Встречные требования A к B и B к A не взаимозачитывают автоматически.
В выбранном направлении требование A положительно, обязательство B отрицательно. Это нормализация для сверки, а не универсальный знак бухгалтерского счёта. Исходные суммы и стороны сохраняют. Возвраты и кредитовые документы требуют явной связи с исходным обязательством; модуль суммы не заменяет такую связь. Денежная единица всегда включает валюту и масштаб.
Фиксируют отчётную дату, правило определения открытого остатка с учётом погашений, книгу, периметр, версии справочников и два входных снимка. business_date определяет учётную дату; observed_at - момент известности версии EDWH. Единый cutoff известности с явным часовым поясом ограничивает обе стороны, но не гарантирует своевременную доставку: состояние полноты каждого источника регистрируют отдельно. Отсутствие позиции в неполном снимке означает неопределённость, а не подтверждённый нулевой долг.
Сначала сравнивают остатки в одной валюте документа. Разные функциональные валюты компаний не делают локальные суммы сопоставимыми. При необходимости общей валюты закрепляют отдельный basis, направление котировки, источник, дату и версию курса и округление по контракту конвертации. Разницу исходных остатков и разницу пересчёта показывают раздельно. Не суммируют RUB и EUR; допуск задают для конкретной валюты и basis.
Сначала валидируют ключи, справочники, полноту и срез. Затем строят кандидатов по паре компаний, направлению, валюте и согласованной ссылке на документ: например, ID счёта продавца с годом и эмитентом. Один номер без контекста может повторяться. Нормализация номера должна быть версионирована и не уничтожать значимые различия.
Однозначное совпадение рассматривают раньше группового. Несколько позиций одной стороны могут соответствовать одной позиции другой, если подтверждена общая ссылка. Их агрегируют внутри группы до сравнения, а не соединяют все строки со всеми. Поиск по близкой сумме или дате создаёт предложение для проверки, а не доказанное совпадение. Если несколько кандидатов равноправны, результат остаётся неоднозначным.
Для частичного совпадения сохраняют связи позиций, назначенную величину каждой стороны и неназначенный остаток. Одна и та же часть позиции не может использоваться повторно в другом назначении этого запуска. Сопоставление не меняет исходный учёт и не проводит корректировку.
Воспроизводимость обеспечивают run_id, версии входов и правил, список членов группы, результаты и история решений. Альтернатива документному matching - сверка агрегатов по паре и валюте: она дешевле, но не объясняет компенсирующие ошибки и требует явно ограниченного вывода.
Синтетическая арифметическая иллюстрация в целых копейках RUB: A показывает требование +10000, B показывает две связанные позиции -6000 и -3000. Для группы разница равна 10000 - 6000 - 3000 = 1000. Можно назначить 9000 с каждой стороны, оставив у A 1000. Это частичное согласование, а не полное совпадение. Без подтверждённой общей ссылки даже совпавшие 9000 остаются кандидатом.
Контрольные инварианты проектного контракта:
Каждая допустимая входная позиция включена в результат или явно отклонена с причиной; односторонние позиции не исчезают при соединении.
Для каждой позиции исходная подписанная сумма равна назначенным частям плюс неназначенный остаток; знак сохраняется.
Назначения не превышают доступный остаток позиции и не используют одну часть дважды.
Итоги по паре, направлению и валюте воспроизводятся из членов групп; исходные суммы не размножаются.
Нулевой итог пары не скрывает положительные и отрицательные расхождения разных документов.
Исполняемых SQL/Python примеров здесь нет; алгоритм и арифметическая иллюстрация не являются проверенным кодом и не зависят от поведения конкретной СУБД.
Разделяют несовпадение идентичности партнёра, односторонний документ, разные погашения, разную дату признания, различие исходной суммы, валютного basis и округления. Причина должна иметь подтверждение: ссылка на позицию, платёж, версию курса или позднюю доставку. Предположение о причине хранится отдельно от согласованного объяснения.
Допуск классифицирует величину, но не удаляет её. Результат различает точное совпадение, частичное совпадение, неоднозначность, отсутствие встречной позиции и неполный вход. Принятие объяснённого расхождения ответственными сторонами сохраняется отдельно от числового результата. Исправление приходит новой версией входа или отдельной учётной корректировкой; прежний протокол остаётся доступным.
Обзор SAP Learning рассматривает matching и reconciliation в SAP S/4HANA, включая причины расхождений по времени и валюте. Manage Assignments описывает работу с назначениями ведущей и партнёрской стороны. Это примеры возможностей продукта, а не спецификация предложенного EDWH-контракта. Для внедрения нужно отдельно выбрать релиз и проверить доступные функции; статья не даёт инструкций настройки SAP.
Почему нулевая разница по паре не доказывает согласование документов?
Как отличить позднюю доставку от отсутствующего обязательства на cutoff?
Как доказать, что групповое сопоставление не использовало одну позицию дважды?
После согласования документов см. исключение внутригрупповых оборотов: сверка задолженности сама по себе не подтверждает согласование дохода и расхода для консолидационной корректировки.
Before consolidation, determine why company A's receivable from company B differs from B's corresponding payable to A. This compares two independent accounting representations rather than checking a copy of one event set. Different local document IDs are acceptable; equal amounts without a confirmed document relationship are insufficient.
The following proposed EDWH contract covers trade receivables and payables within an agreed group perimeter. Elimination, foreign-operation translation, loans, and the full consolidation process are outside its scope. Matching rules and acceptance of differences are not presented as IFRS requirements. This material describes neither the author's experience nor a lab implementation.
The input grain is the outstanding balance of one document item at the reporting date, in a selected legal entity ledger and document currency. Its key includes source system, legal entity, ledger, document, and item; the snapshot version is stored separately. If a source provides only an aggregate counterparty balance, reconciliation can cover that level but cannot claim agreement on individual documents.
A versioned master-data mapping links each local customer or supplier to a group legal entity. Check reciprocity: A identifies B as its partner, and B identifies A. An unknown or ambiguous mapping blocks automatic matching. A canonical pair key orders two stable IDs while preserving the direction of the claim. Opposing claims from A to B and B to A are not automatically netted.
For the selected direction, A's receivable is positive and B's payable is negative. This is reconciliation normalization, not a universal account sign convention. Preserve original amounts and sides. Returns and credit documents need an explicit relationship to the original obligation; an absolute amount cannot replace that relationship. Every monetary unit includes currency and scale.
Fix the reporting date, the rule for determining outstanding balances after settlements, ledger, perimeter, master-data versions, and both input snapshots. business_date identifies the accounting date; observed_at identifies when the EDWH learned of a version. A shared knowledge cutoff with an explicit timezone limits both sides but does not guarantee timely delivery: record source completeness separately. An absent item in an incomplete snapshot means uncertainty, not a confirmed zero debt.
First compare balances in the same document currency. Different functional currencies do not make local amounts comparable. If a common currency is required, fix a separate basis, quotation direction, rate source, effective date, rate version, and rounding under the currency conversion contract. Show differences in original balances separately from conversion differences. Do not add RUB and EUR; define tolerance for a specific currency and basis.
First validate keys, master data, completeness, and snapshot boundaries. Then identify candidates using entity pair, direction, currency, and an agreed document reference, such as the seller's invoice ID together with its year and issuer. A number alone may recur. Reference normalization must be versioned and preserve meaningful distinctions.
Consider unambiguous matches before group matching. Several items on one side may correspond to one on the other if a shared reference is confirmed. Aggregate within the group before comparison instead of joining every row to every other row. Similar amounts or dates produce a review suggestion rather than a proven match. If several candidates are equally plausible, the result remains ambiguous.
For a partial match, retain item relationships, the amount assigned on each side, and the unassigned remainder. The same portion of an item cannot be reused in another assignment within this run. Matching does not change the original accounting records or post an adjustment.
Reproducibility requires run_id, input and rule versions, group membership, results, and decision history. An alternative to document matching is aggregate reconciliation by pair and currency: it costs less but cannot explain offsetting errors and requires an explicitly limited conclusion.
A synthetic arithmetic illustration using integer kopecks of RUB: A reports a receivable of +10000; B reports two linked items of -6000 and -3000. The group difference is 10000 - 6000 - 3000 = 1000. Assigning 9000 on each side leaves 1000 at A. This is partial agreement rather than a full match. Without a confirmed shared reference, even the corresponding 9000 remains a candidate.
Control invariants of the proposed contract:
Every eligible input item appears in the result or is explicitly rejected with a reason; one-sided items do not disappear in a join.
For each item, the original signed amount equals its assigned portions plus its unassigned remainder; signs are preserved.
Assignments do not exceed the available item balance or reuse the same portion.
Totals by pair, direction, and currency can be reproduced from group members; source amounts are not multiplied.
A zero pair total does not conceal positive and negative differences across documents.
There are no executable SQL/Python examples here. The algorithm and arithmetic illustration are not verified code and do not depend on a particular DBMS's behavior.
Distinguish partner identity mismatches, one-sided documents, different settlements, different recognition dates, original-amount differences, currency-basis differences, and rounding. A reason needs evidence: a reference to an item, payment, rate version, or late delivery. Store a suspected reason separately from an agreed explanation.
Tolerance classifies a difference without deleting it. Results distinguish exact agreement, partial agreement, ambiguity, an absent counterpart item, and incomplete input. Responsible parties' acceptance of an explained difference is recorded separately from the numerical result. A correction arrives as a new input version or a separate accounting adjustment; the earlier reconciliation record remains available.
The SAP Learning overview discusses matching and reconciliation in SAP S/4HANA, including timing and currency differences. Manage Assignments describes assignments for leading and partner sides. These illustrate product capabilities rather than specifying the proposed EDWH contract. An implementation must select a release and verify available features separately; this article does not provide SAP configuration instructions.
Why does a zero pair difference fail to prove agreement on documents?
How can late delivery be distinguished from an absent obligation at cutoff?
How can you prove that group matching did not use an item twice?
After reconciling documents, see intercompany turnover elimination: reconciling receivables and payables alone does not establish that revenue and expense have been agreed for a consolidation adjustment.