Задача и границы#
В самостоятельной отчётности компании A доход от услуги компании B и расход B допустимы, но групповой показатель должен учитывать утверждённые консолидационные корректировки. Задача EDWH - сохранить исходные обороты и отдельно построить воспроизводимый слой исключений, а не удалить внутренние операции из журналов компаний.
Рассматривается проектный контракт для согласованной услуги, полностью признанной доходом и расходом в одном периоде двумя компаниями выбранного периметра. Исключение остатков задолженности, нереализованной прибыли в запасах, инвестиций, налоговых эффектов, денежных потоков и изменение периметра внутри периода вне рамок. Это не полная реализация консолидации, не лабораторный результат и не опыт автора. Исполняемых SQL/Python примеров нет.
Стандарт, продукт и проектное решение#
Официальный обзор IFRS 10 определяет консолидированную отчётность как представление группы в качестве единой экономической единицы. Обзор не задаёт ключей EDWH, очередности загрузок или политики обработки расхождений. Применимую редакцию полного стандарта и учётную политику определяет ответственный за отчётность; доступ к полному тексту может требовать регистрации или подписки.
Урок SAP показывает вариант, где инициатором исключения доходов и затрат служат данные продавца, а записи создаются для обеих сторон. Это свойство описанного продуктового сценария, а не универсальный алгоритм. Ниже выбран более узкий двухсторонний контракт: он требует подтверждённых оборотов обеих сторон. При отсутствии детализации покупателя нельзя заявлять документное согласование; односторонний метод потребует отдельной политики и контролей. Статья не является инструкцией настройки конкретного релиза SAP и не утверждает поведения какой-либо СУБД.
Зерно, пара, период и версии#
Зерно входа - строка признанного дохода или расхода по документу услуги в зафиксированном снимке книги юридического лица. Ключ включает систему, юридическое лицо, книгу, документ, строку и версию события. Дебет положителен, кредит отрицателен: доход A имеет отрицательный знак, расход B положительный. Это соглашение примера. Сумма хранится в целых минимальных единицах с явно закреплёнными валютой и масштабом.
Пара имеет канонический ключ двух компаний, но направление продавец-покупатель сохраняется. Обе компании должны входить в одну утверждённую версию периметра. business_date относит оборот к периоду, observed_at ограничивает известность версии единым cutoff с часовым поясом. Фиксируют также полноту источников: отсутствие расхода в неполном снимке не означает нулевой расход.
Зерно выхода - строка консолидационной корректировки внутри документа исключения, отдельно от локального учёта. Манифест выпуска содержит release_id, период, группу, версии периметра, входов, правил исключения, отображения статей, валютного basis и протокола согласования. Версия правила закрепляет допустимые статьи, направления, критерии допуска, знаки и порядок обработки разницы; изменение правила создаёт новый выпуск.
Согласование входа и порядок валютного basis#
Межфирменная сверка разбирает остатки требований и обязательств. Её результат помогает установить связь документов, но не доказывает равенство оборотов дохода и расхода: оплата могла закрыть задолженность, а расход мог быть капитализирован. Здесь нужен отдельный протокол согласования именно признанных оборотов услуги с их исходными строками и версиями. Алгоритм поиска пар повторно не рассматривается.
До исключения проверяют принадлежность периметру, период, встречность партнёров, отсутствие повторного назначения строк и подтверждение допуска. Частичное совпадение, неизвестный партнёр и неполный вход блокируют автоматическое исключение этой группы в выбранном узком контракте. Допуск не разрешает молча удалить разницу. Коррекция источника или отдельное утверждённое решение сохраняются с происхождением; это проектная политика допуска, а не разрешение оставить обязательное бухгалтерское исключение невыполненным. Нерешённые группы блокируют готовность соответствующего выпуска.
Сначала согласуют экономическую величину в валюте операции, затем приводят обе стороны к утверждённому basis групповой витрины, затем формируют корректировки в этом же basis. Не сравнивают непосредственно разные функциональные валюты. Контракт конвертации задаёт курс, направление котировки, дату, версию и округление. Разные курсы могут дать разные групповые суммы даже при совпадении исходных величин. Разницу пересчёта отделяют от расхождения операции; порядок её признания задаёт отдельная учётная политика. Самостоятельный выбор общего курса ради равенства сторон недопустим.
Синтетический пример и симметричность#
Допустим, утверждённый basis - RUB с масштабом 2, обе стороны уже приведены к нему без разницы пересчёта. A признала доход -10000 копеек, B расход +10000 копеек за полностью потреблённую услугу. Обе строки принадлежат одному периоду и подтверждённой группе согласования.
| Строка |
До исключения, копейки RUB |
Корректировка |
После исключения |
| Доход A |
-10000 |
+10000 |
0 |
| Расход B |
+10000 |
-10000 |
0 |
| Сумма двух строк |
0 |
0 |
0 |
Корректировка дебетует доход и кредитует расход в консолидационном слое. Симметричность означает, что обе стороны одной допустимой операции исключены согласованно, а не что каждая компания получила самостоятельный сбалансированный локальный документ. В примере баланс проверяется у документа исключения на уровне группы в одной валюте. Если модель требует баланс по каждой единице, нужны отдельно утверждённые технические встречные статьи и контроль их погашения на уровне группы.
При расходе B +9900 копеек простое обращение знаков даст несбалансированную корректировку +100. Исключить по 10000 с обеих сторон тоже неверно: у B появится остаток -100. Выбранный контракт блокирует такой документ до решения расхождения. Нулевая общая сумма исходного набора ничего не доказывает: доход и расход проверяют раздельно. Арифметика таблицы является иллюстрацией, не результатом исполнения кода.
Повторное применение и альтернативы#
Псевдокод процесса, не проверенная реализация:
Закрепить исходный снимок без консолидационных корректировок.
Проверить входы, версии правил и протоколы согласования оборотов.
Получить допустимые группы в утверждённом валютном basis.
Сформировать документ исключения и связи с исходными строками.
Проверить баланс, покрытие и отсутствие повторного использования.
Опубликовать целый выпуск исходных данных и корректировок.
Идентичность логического документа включает группу, период, basis, правило и группу согласования в пределах выпуска. run_id попытки исполнения хранится отдельно: новый запуск не создаёт новое экономическое исключение. Повтор тех же зависимостей должен дать тот же набор строк; конфликт содержания под тем же ключом блокируется. Генератор никогда не читает собственные исключения как исходный оборот.
При изменении входов или правил новый выпуск заменяет активное представление целиком; прежний остаётся для аудита. Нельзя суммировать корректировки старого и нового выпуска. Альтернатива для накопительного журнала - явное сторно прежнего документа и новый документ, с отдельной проверкой цепочки. Смешивать эти стратегии опасно. Согласованное переключение результата - требование проекта; механизмы транзакций и конкурентного доступа выбранной СУБД требуют самостоятельной проверки.
Контроли, связи и вопросы#
Для каждой группы и валютного basis проверяют баланс документа, противоположность корректировок допущенным входным суммам по каждой статье, охват обеих сторон и уникальность использования исходной доли. Отдельно проверяют, что внешние обороты не изменились, исключённые суммы не превысили допущенные и итог равен исходному набору плюс корректировки выбранного выпуска. Баланс всей витрины не заменяет эти проверки.
Граничные случаи: позднее сторно, разные периоды признания, отрицательная услуга/возврат, повторная доставка, смена периметра, отсутствующий курс и уже исключённый вход. Для возврата применяют знаковую корректировку подтверждённой операции, а не модуль суммы. Позднее изменение инвалидирует затронутый выпуск по контракту закрытия; lineage показателя связывает каждую корректировку с входными строками, согласованием и версией правила. Это перечень требуемых проверок будущей реализации, не заявление об успешных тестах.
- Почему сверка погашенной задолженности не доказывает согласование дохода и расхода?
- Где должен балансироваться документ, если корректировки распределены между компаниями?
- Как повторный запуск после смены курса может удвоить исключение и как этого избежать?
Problem and scope#
In company A's separate financial statements, revenue from a service supplied to company B and B's expense can be valid, while a group measure must include approved consolidation adjustments. The EDWH's job is to preserve the original turnover and build a separate, reproducible elimination layer, rather than remove internal transactions from company journals.
This proposed contract covers an agreed service fully recognized as revenue and expense in the same period by two companies within the selected group scope. Eliminating outstanding receivables and payables, unrealized inventory profit, investments, tax effects, cash flows, and changes in scope during the period is outside its boundaries. This is neither a complete consolidation implementation, a lab result, nor the author's experience. There are no executable SQL/Python examples.
Standard, product, and project decision#
The official IFRS 10 overview describes consolidated financial statements as presenting the group as a single economic entity. The overview does not prescribe EDWH keys, load sequencing, or discrepancy handling. The reporting owner determines the applicable edition of the full standard and the accounting policy; access to the full text may require registration or a subscription.
The SAP lesson illustrates an approach in which seller data triggers revenue and cost elimination and entries are created for both sides. This is a feature of the described product scenario, rather than a universal algorithm. The narrower bilateral contract below requires confirmed turnover from both parties. Without buyer detail, document-level agreement cannot be claimed; a unilateral method would need its own policy and controls. This article is not a configuration guide for a particular SAP release and makes no claims about any database system's behavior.
Grain, pair, period, and versions#
Input grain is one recognized revenue or expense line for a service document in a fixed snapshot of a legal entity's ledger. Its key includes system, legal entity, ledger, document, line, and event version. Debit is positive and credit negative: A's revenue is negative and B's expense positive. This is the example's convention. Amounts use integer minor units with an explicit currency and scale.
The pair has a canonical key identifying two companies, while retaining seller-to-buyer direction. Both companies must belong to the same approved scope version. business_date assigns turnover to a period; observed_at limits version knowledge at a common, timezone-aware cutoff. Source completeness is recorded separately: missing expense in an incomplete snapshot does not establish zero expense.
Output grain is one consolidation adjustment line within an elimination document, separate from local accounting. The release manifest records release_id, period, group, and versions of the scope, inputs, elimination rules, reporting-item mappings, currency basis, and agreement record. A rule version fixes eligible items, directions, admission criteria, signs, and discrepancy handling; changing a rule creates a new release.
Input agreement and currency basis sequence#
Intercompany reconciliation addresses outstanding receivables and payables. Its result can help establish document relationships, but does not prove that revenue and expense turnover agree: payment may have settled the debt, or the buyer may have capitalized the cost. This contract needs a separate agreement record for recognized service turnover, referencing original lines and versions. The pair-finding algorithm is not repeated here.
Before elimination, check scope membership, period, reciprocal partners, absence of repeated line assignments, and confirmed admission. Partial matches, unknown partners, and incomplete inputs block automatic elimination of that group under this narrow contract. A tolerance does not authorize silently removing the difference. Source corrections or separately approved decisions retain their provenance. This is a project admission policy, not permission to leave a required accounting elimination unperformed. Unresolved groups block readiness of the affected release.
First agree the economic amount in transaction currency, then translate both sides to the approved group mart basis, then generate adjustments in that same basis. Do not directly compare different functional currencies. The conversion contract fixes the rate, quotation direction, date, version, and rounding. Different rates can produce different group amounts even when original amounts agree. Separate translation differences from transaction discrepancies; their recognition follows a separate accounting policy. Choosing a common rate simply to force agreement is unacceptable.
Synthetic example and symmetry#
Assume the approved basis is RUB with scale 2, and both sides have already been translated to it without a translation difference. A recognized revenue of -10000 kopecks and B expense of +10000 kopecks for a fully consumed service. Both lines belong to the same period and a confirmed agreement group.
| Line |
Before elimination, RUB kopecks |
Adjustment |
After elimination |
| A's revenue |
-10000 |
+10000 |
0 |
| B's expense |
+10000 |
-10000 |
0 |
| Sum of both lines |
0 |
0 |
0 |
The adjustment debits revenue and credits expense in the consolidation layer. Symmetry means both sides of an eligible transaction are eliminated consistently, rather than each company receiving a separately balanced local document. In this example, the elimination document is balanced at group level in one currency. If the model requires balance for each unit, separately approved technical offset items and a check that they cancel at group level are needed.
If B's expense is +9900 kopecks, simply reversing the signs creates an unbalanced adjustment of +100. Eliminating 10000 on both sides is also wrong: B would retain -100. This contract blocks that document until the discrepancy is resolved. A zero total for the original dataset proves nothing by itself: revenue and expense are checked separately. The table's arithmetic is an illustration, not the result of executing code.
Repeated application and alternatives#
Process pseudocode, not a verified implementation:
Fix the original snapshot, excluding consolidation adjustments.
Validate inputs, rule versions, and turnover agreement records.
Identify eligible groups in the approved currency basis.
Generate elimination documents and links to original lines.
Check balance, coverage, and absence of repeated use.
Publish a complete release of original data and adjustments.
Logical document identity includes group, period, basis, rule, and agreement group within the release. The execution attempt's run_id is separate: a new attempt does not create a new economic elimination. Repeating the same dependencies must produce the same set of lines; conflicting content under the same key is blocked. The generator never reads its own eliminations as original turnover.
When inputs or rules change, a new release replaces the entire active view; the previous release remains available for audit. Adjustments from old and new releases must not be added together. An alternative for an accumulating journal is an explicit reversal of the previous document followed by a new document, with a separate chain check. Mixing these strategies is unsafe. Consistent switching of results is a project requirement; transaction and concurrency mechanisms in the chosen database require independent verification.
Controls, connections, and questions#
For each group and currency basis, check document balance, adjustments opposite to admitted input amounts for each reporting item, coverage of both sides, and unique use of each original portion. Separately verify that external turnover is unchanged, eliminated amounts do not exceed admitted amounts, and the result equals original data plus adjustments from the selected release. Whole-mart balance does not replace these checks.
Boundary cases include late reversals, different recognition periods, negative services or returns, repeated delivery, scope changes, missing rates, and already eliminated inputs. For a return, apply a signed adjustment to the confirmed transaction rather than using its absolute amount. A late change invalidates the affected release under the period-close contract; metric lineage links each adjustment to input lines, agreement, and rule version. These are required checks for a future implementation, not a claim of successful tests.
- Why does reconciliation of settled debt not prove that revenue and expense agree?
- Where must a document balance if its adjustments are distributed between companies?
- How can rerunning after a rate change double an elimination, and how can this be prevented?