Задача и границы#
Нужно получить стоимость открытого валютного денежного остатка в функциональной валюте на конец отчётного периода и объяснить разницу с его учётной стоимостью перед пересчётом. Конвертация отдельных оборотов и пересчёт конечного остатка отвечают на разные вопросы: сумма оборотов по историческим курсам не заменяет оценку остатка на отчётную дату.
Предмет статьи - денежные статьи в иностранной валюте, например денежные средства и требования или обязательства получить либо уплатить фиксированное или определимое число денежных единиц. Наличие валютного кода само по себе не доказывает денежную классификацию. Классификацию и функциональную валюту закрепляет утверждённая учётная политика, DWH сохраняет решение и его версию.
Немонетарные статьи, трансляция зарубежных операций и пересчёт в валюту представления, деривативы и hedge accounting здесь не рассматриваются. Специальные случаи отсутствия обменяемости, гиперинфляции и чистой инвестиции в зарубежную операцию требуют отдельного анализа. Статья knowledge описывает проектный контракт, не опыт автора и не реализованный лабораторный расчёт.
Стандарт и проектный контракт#
Официальная страница IAS 21 объясняет назначение стандарта и функциональную валюту. Страница поддержки содержит материалы по применению. Полный текст на сайте IFRS Foundation может требовать подписки; обзор и материалы поддержки не заменяют применимую редакцию стандарта.
Для открытого первоисточника можно обратиться к IAS 21 в приложении к Регламенту ЕС 2023/1803: пункт 8 определяет денежные статьи и closing rate, пункт 23(a) предусматривает пересчёт валютных денежных статей по closing rate на конец периода, а пункт 28 устанавливает общее правило признания курсовых разниц с исключениями. Это опубликованная редакция, принятая ЕС в 2023 году, а не утверждение о составе всех последующих поправок или применимости права ЕС к любой организации. Для конкретного отчёта проверяют юрисдикцию, дату вступления поправок в силу и редакцию политики.
Далее предлагаются поля и контроли EDWH. Стандарт не предписывает их названия, идентификатор запуска или алгоритм хранения. Утверждённая политика конкретизирует источник и тип допустимого closing rate, правила округления и обработку исключений в пределах применимых требований. Она не может произвольно отменить эти требования. Отсутствующий курс нельзя автоматически заменить нулём или последним известным значением.
Зерно, база и временные отсечки#
В предлагаемой модели строка входа - открытая денежная позиция на дату отчёта: юридическое лицо, книга, счёт, идентификатор позиции, исходная валюта и версия снимка. Для денежного счёта идентификатором может служить согласованная аналитика счёта, для дебиторской задолженности - открытая позиция документа. Несколько строк одной позиции агрегируют до этого зерна до присоединения курсов. Выбор зерна округления является частью политики.
Сохраняют два разных значения: foreign_balance в основных единицах иностранной валюты и functional_basis в основных единицах функциональной валюты перед текущей корректировкой. В примере дебет положителен, кредит отрицателен. Масштаб каждой валюты и точность вычислений заданы отдельно. Остатки по разным датам не суммируются.
basis_id указывает, как получена база: снимок книги, набор проводок и включённые предыдущие переоценки. Это не просто исходная сумма при первом признании. Если книга уже содержит переоценку за текущую дату, её нельзя повторно включить как новую корректировку; нужен отдельный режим сверки уже переоценённого остатка.
| Поле |
Смысл |
reporting_date, business_date |
Дата оценки и учётная дата входных движений |
knowledge_cutoff |
Отсечка доступности версий данных для этого выпуска |
observed_at, available_at |
Получение версии и её доступность после проверок |
snapshot_id, basis_id |
Версии валютного остатка и функциональной базы |
functional_currency, classification_version |
Функциональная валюта и решение о денежной классификации |
rate_id, rate_date, rate_type, provider |
Закреплённая версия курса, дата действия, тип и источник |
policy_version, rounding_rule, run_id |
Правила оценки, округление и версия результата |
Отчётная дата и отсечка знаний различаются. Выпуск за 31 января может использовать данные, принятые 2 февраля, если это разрешено контрактом выпуска. Поздняя корректировка остатка или курса создаёт новый выпуск с объяснимым мостом изменений. Дату действия курса не подменяют временем загрузки. Для отсечек timestamp фиксируют часовой пояс и включение границы, например available_at <= knowledge_cutoff.
Расчёт и синтетический пример#
Пусть r выражен в основных единицах функциональной валюты за одну основную единицу иностранной валюты. Тогда target = round(foreign_balance * r) и adjustment = target - functional_basis. Первое значение - оценка состояния, второе - разница с согласованной базой. Эта формула не определяет автоматически счёт признания, курсовой результат периода или его представление в отчёте.
Синтетическая дебиторская позиция имеет остаток +100 USD, база составляет +9000 RUB, выбранный курс на дату отчёта равен 95 RUB/USD. Округление в примере выполняется до двух десятичных знаков RUB. Целевая стоимость равна +9500.00 RUB, корректировка равна +500.00 RUB. Для кредиторской позиции -100 USD с базой -9000 RUB получаем -9500.00 RUB и -500.00 RUB. Одинаковое изменение курса даёт разные последствия для актива и обязательства; знак корректировки не является универсальным знаком прибыли.
Если в базу дебиторской позиции уже вошла предыдущая переоценка +300 RUB, база равна +9300 RUB, и новая разница составляет +200 RUB, а не +500 RUB. Если переоценка текущей даты уже отражена и база равна +9500 RUB, сверка должна дать ноль при тех же входах. Повторное прибавление +500 RUB завысило бы стоимость.
Примеры являются арифметической иллюстрацией, не SQL/Python и не тестом СУБД. Разделение разниц по погашенным и открытым позициям, счёт признания и направление корректирующей проводки задают отдельно по утверждённой политике с учётом исключений IAS 21. EDWH может только сверять результат ERP либо рассчитывать предложение для последующего утверждения; эти режимы не должны смешиваться.
Последовательность и альтернативы#
Ниже псевдокод, не исполняемый SQL или Python:
Закрепить дату отчёта, cutoff знаний, снимки и версию политики.
Отобрать открытые позиции с подтверждённой денежной классификацией.
Проверить валютный остаток и функциональную базу на одном зерне.
Установить, какие переоценки уже включены в базу.
Для каждой позиции разрешить ровно одну допустимую версию курса.
Рассчитать целевую стоимость и разницу с базой на зерне округления.
Сохранить входы, результат, происхождение и статус контролей.
Сверить результаты; передать корректировки только в разрешённом режиме.
Расчёт по открытым позициям позволяет объяснять погашения и округление, но требует согласованного состояния каждой позиции. Агрегирование по счёту и валюте уменьшает объём, однако может потерять детализацию базы и дать другую сумму округления. Выбор зависит от учётного процесса, а не от удобства SQL. Общий контракт курса и правила точности здесь используются без повторения их алгоритмов.
Ни одна СУБД не определяет денежную классификацию или допустимый курс. Десятичная арифметика, транзакционный снимок и ограничения уникальности помогают реализовать контракт, но сами по себе не доказывают финансовую корректность. Исполняемого решения для PostgreSQL или SQLite в этой статье нет.
Инварианты и граничные случаи#
На ключ позиции и запуск должна приходиться одна строка результата и одна разрешённая версия курса. Контролируют покрытие всех ожидаемых позиций, отсутствие размножения при соединениях и равенство functional_basis + adjustment = target в согласованной точности. Итоги сверяют отдельно по юридическому лицу, книге, счёту и валютной паре. Нулевой общий итог разниц не доказывает полноту.
Частичное погашение меняет валютный остаток и связанную с ним базу. Нельзя пересчитывать первоначальную сумму документа вместо открытой части. При нулевом валютном остатке и ненулевой функциональной базе требуется расследование погашения, округления или уже проведённых корректировок; молчаливое списание всей базы недопустимо. Позиция в функциональной валюте не получает валютную переоценку; расхождение в ней проверяют отдельно.
Отсутствие курса, неоднозначная классификация, неизвестная база и конфликт версий блокируют окончательный результат. Отдельно проверяют выходной день на отчётную дату, исправление курса после cutoff, изменение состава открытых позиций и включённую в базу текущую переоценку. При отсутствии обменяемости обычный путь расчёта останавливают и передают вопрос на оценку по применимым требованиям IAS 21. Это не разрешение самовольно переносить последнюю котировку.
Повтор с теми же снимками и правилами воспроизводит суммы. Новый выпуск объясняет изменения отдельно по валютному остатку, базе, версии курса и политике. При автоматической обратной проводке переоценки в следующем периоде её идентификатор сохраняют; такой процесс допустим только при явно утверждённом порядке. Сам расчёт состояния не создаёт ни обратную проводку, ни повторную корректировку.
Связанные темы и вопросы#
Алгебра состояния разобрана в остатках и оборотах, версии выпуска - в закрытии периода, происхождение результата - в финансовой lineage.
- Как установить, какие переоценки уже входят в функциональную базу?
- Почему сумма конвертированных оборотов не заменяет пересчёт открытого остатка?
- Какие контроли отличают новую корректировку от сверки уже переоценённой книги?
Purpose and scope#
The goal is to measure an outstanding foreign currency monetary balance in the functional currency at the end of a reporting period and explain the difference from its carrying amount before remeasurement. Converting individual movements and remeasuring a closing balance answer different questions: movements translated at historical rates do not replace a reporting-date measurement of the balance.
This article covers foreign currency monetary items, such as cash and rights or obligations to receive or pay a fixed or determinable number of currency units. A currency code alone does not establish monetary classification. Approved accounting policy establishes the classification and functional currency; the DWH preserves the decision and its version.
Non-monetary items, translation of foreign operations and translation into a presentation currency, derivatives, and hedge accounting are outside scope. Lack of exchangeability, hyperinflation, and a net investment in a foreign operation require separate analysis. This knowledge article describes a proposed contract, not the author's experience or an implemented lab calculation.
The standard and the proposed contract#
The official IAS 21 page explains the standard's purpose and functional currency. The support page provides implementation materials. The full text on the IFRS Foundation website may require a subscription; summaries and support materials do not replace the applicable edition of the standard.
An openly available primary source is IAS 21 in the annex to EU Regulation 2023/1803: paragraph 8 defines monetary items and the closing rate, paragraph 23(a) requires foreign currency monetary items to be translated at the closing rate at period end, and paragraph 28 sets the general rule for recognising exchange differences, subject to exceptions. This is the published text adopted by the EU in 2023, not a claim about all subsequent amendments or the applicability of EU law to every entity. For a particular report, check the jurisdiction, effective dates of amendments, and policy version.
The fields and controls below are EDWH design proposals. The standard does not prescribe their names, a run identifier, or a storage algorithm. Approved policy specifies the source and type of an acceptable closing rate, rounding rules, and exception handling within applicable requirements. It cannot arbitrarily override those requirements. A missing rate must not automatically be replaced with zero or the last known value.
Grain, basis, and time cutoffs#
In this proposed model, one input row represents an outstanding monetary position at the reporting date: legal entity, ledger, account, position identifier, source currency, and snapshot version. For a cash account, the identifier may be the agreed account dimensions; for a receivable, it may identify an open document item. Aggregate multiple rows belonging to a position to this grain before joining rates. The rounding grain is part of policy.
Preserve two distinct measures: foreign_balance in major units of the foreign currency and functional_basis in major units of the functional currency before the current adjustment. In the example, debits are positive and credits negative. Each currency's scale and calculation precision are defined separately. Balances at different dates are not added together.
The basis_id records how the basis was derived: the ledger snapshot, journal entries, and earlier remeasurement adjustments included. It is not simply the amount at initial recognition. If the ledger already includes remeasurement for the current date, it must not be included again as a new adjustment; use a separate reconciliation mode for an already remeasured balance.
| Field |
Meaning |
reporting_date, business_date |
Measurement date and accounting date of input movements |
knowledge_cutoff |
Cutoff for data versions available to this release |
observed_at, available_at |
Receipt of a version and its availability after checks |
snapshot_id, basis_id |
Versions of the foreign currency balance and functional carrying basis |
functional_currency, classification_version |
Functional currency and monetary classification decision |
rate_id, rate_date, rate_type, provider |
Fixed rate version, effective date, type, and source |
policy_version, rounding_rule, run_id |
Measurement rules, rounding, and result version |
The reporting date and knowledge cutoff differ. A January 31 release may use data accepted on February 2 if the release contract allows it. A late correction to a balance or rate creates a new release with an explainable bridge of changes. Do not substitute load time for a rate's effective date. For timestamp cutoffs, define the time zone and boundary inclusion, for example available_at <= knowledge_cutoff.
Calculation and a synthetic example#
Let r be expressed in major units of the functional currency per one major unit of the foreign currency. Then target = round(foreign_balance * r) and adjustment = target - functional_basis. The first value measures a state; the second is the difference from an agreed basis. This formula does not automatically determine a recognition account, the period's exchange gain or loss, or its presentation in a report.
A synthetic receivable has an outstanding balance of +100 USD, a basis of +9000 RUB, and a selected reporting-date rate of 95 RUB/USD. The example rounds to two decimal places in RUB. The target amount is +9500.00 RUB and the adjustment is +500.00 RUB. A payable of -100 USD with a basis of -9000 RUB produces -9500.00 RUB and an adjustment of -500.00 RUB. The same rate change has different consequences for an asset and a liability; the adjustment's sign is not a universal sign of profit.
If an earlier +300 RUB remeasurement is already included in the receivable's basis, the basis is +9300 RUB and the new difference is +200 RUB, not +500 RUB. If the current-date remeasurement is already posted and the basis is +9500 RUB, reconciliation should return zero with the same inputs. Adding +500 RUB again would overstate the carrying amount.
These examples illustrate arithmetic; they are neither SQL/Python nor DBMS tests. The split between differences on settled and outstanding positions, recognition accounts, and the direction of adjusting entries must be specified separately by approved policy, taking IAS 21 exceptions into account. The EDWH may reconcile an ERP result or calculate a proposal for subsequent approval; these modes must not be mixed.
Processing sequence and alternatives#
The following is pseudocode, not executable SQL or Python:
Fix the reporting date, knowledge cutoff, snapshots, and policy version.
Select outstanding positions with confirmed monetary classification.
Check the foreign balance and functional basis at the same grain.
Establish which remeasurement adjustments are already included in the basis.
Resolve exactly one acceptable rate version for each position.
Calculate the target amount and difference at the rounding grain.
Preserve inputs, results, provenance, and control status.
Reconcile results; pass adjustments onward only in the authorised mode.
Calculating by open item supports explanations of settlement and rounding, but requires an agreed state for each position. Aggregating by account and currency reduces volume, but may lose basis detail and produce a different rounded total. The choice depends on the accounting process, not SQL convenience. The general rate contract and precision rules are reused here without repeating their algorithms.
No DBMS determines monetary classification or an acceptable rate. Decimal arithmetic, transaction snapshots, and uniqueness constraints help implement the contract, but do not by themselves establish financial correctness. This article contains no executable PostgreSQL or SQLite solution.
Invariants and boundary cases#
There must be one result row and one resolved rate version per position key and run. Check coverage of all expected positions, absence of join multiplication, and functional_basis + adjustment = target at the agreed precision. Reconcile totals separately by legal entity, ledger, account, and currency pair. A zero overall adjustment does not establish completeness.
Partial settlement changes both the foreign balance and its associated basis. Do not remeasure the original document amount instead of its open portion. A zero foreign balance with a nonzero functional basis requires investigation of settlement, rounding, or adjustments already posted; silently writing off the entire basis is unacceptable. A position denominated in the functional currency does not receive foreign currency remeasurement; investigate discrepancies separately.
A missing rate, ambiguous classification, unknown basis, or version conflict blocks a final result. Check a reporting date falling on a non-business day, a rate corrected after the cutoff, changes in open positions, and current remeasurement already included in the basis. If currencies lack exchangeability, stop the ordinary calculation path and refer the issue for assessment under applicable IAS 21 requirements. This does not authorise automatically carrying forward the last quotation.
Repeating the calculation with the same snapshots and rules reproduces the amounts. A new release explains changes separately by foreign balance, basis, rate version, and policy. If a remeasurement is automatically reversed in the next period, preserve the reversal's identifier; this process requires an explicitly approved procedure. Calculating a state does not itself create either a reversing entry or another adjustment.
Related topics and questions#
State algebra is covered in balances and movements, release versions in period close, and result provenance in financial lineage.
- How can you establish which remeasurement adjustments are already included in the functional basis?
- Why does adding converted movements not replace remeasurement of an outstanding balance?
- Which controls distinguish a new adjustment from reconciliation of an already remeasured ledger?