TargetArchitecture_Partial.xlsx

How the model read it

The authoritative register requires an Int64 Account.AccountKey stable identifier. Current gold observes the exact table, column name and data type.

How the model read it

The authoritative register requires a String Account.AccountName. Current gold observes the exact table, column name and data type.

How the model read it

Current gold observes the exact String Account.AccountType column. Structural coverage is direct, although the register definition mentions revenue/expense while the fictional examples also include asset, liability and equity values.

Should AccountType cover the full balance-sheet and P&L domain (Asset, Liability, Equity, Revenue, Expense), rather than only the register's stated revenue-or-expense classification?

How the model read it

The authoritative register requires an Int64 Calendar.DateKey in YYYYMMDD form. Current gold observes the exact table, column name and data type; actual value encoding was not available for verification.

Should the YYYYMMDD encoding and uniqueness of Calendar.DateKey be tested against source/model data during implementation validation?

How the model read it

The authoritative register requires a DateTime Calendar.Date. Current gold observes the exact table, column name and data type.

How the model read it

Current gold observes the exact Int64 Calendar.FiscalMonth column. Workbook context indicates a July fiscal-year start and supplies a formula for month numbering. Gold does not establish that the current model uses that exact derivation and notes that the column is summarised by Sum.

Does the current Calendar.FiscalMonth use the required July-start numbering shown by the workbook formula?

Should Calendar.FiscalMonth be changed from Summarise by Sum to Summarise by None?

How the model read it

The authoritative register requires an Int64 Ledger.DateKey posting-date foreign key. Current gold observes the exact column and an active many-to-one Ledger.DateKey to Calendar.DateKey relationship.

How the model read it

The authoritative register requires an Int64 Ledger.AccountKey account foreign key. Current gold observes the exact column and an active many-to-one Ledger.AccountKey to Account.AccountKey relationship.

How the model read it

The authoritative register requires a Decimal Ledger.SignedAmount in reporting-sign convention. Current gold observes the exact Decimal column. The audit confirms structure and formatting, but not source currency conversion logic or detailed sign semantics.

Is SignedAmount already converted into a single reporting currency, and what conversion-rate/date rules are intended when CurrencyCode is added?

Is the workbook's positive-revenue/negative-expense sign convention the required production convention?

How the model read it

The authoritative register requires a Boolean Ledger.IsAdjustment. Current gold observes the exact table, column name and data type.

What business rule distinguishes late or manual adjustments, and is the current field populated consistently with that rule?

How the model read it

The authoritative register requires Ledger.CostCentre for operating-area accountability, and working sheets illustrate cost-centre codes. The audited Ledger inventory contains only DateKey, AccountKey, SignedAmount and IsAdjustment; no CostCentre object is present in available current gold.

Is CostCentre available in the finance posting source at the same posting grain as Ledger?

Is a separate Cost Centre dimension required, or is a code column on Ledger sufficient?

Who owns the authoritative cost-centre hierarchy and effective-dating rules?

How the model read it

The authoritative register requires an ISO transaction CurrencyCode for transaction-currency analysis, and working sheets illustrate AUD/NZD codes. No CurrencyCode object is present in the audited Ledger inventory in available current gold.

Is transaction currency available on every posting in the finance source?

Are transaction amount, reporting amount and exchange-rate fields also needed to make transaction-currency analysis meaningful?

Should CurrencyCode link to a governed currency dimension?

How the model read it

The authoritative register requires an Account.AccountGroup management roll-up. The audited Account inventory contains AccountKey, AccountName and AccountType only; no AccountGroup object is present in available current gold.

What is the authoritative source and owner for AccountGroup mappings?

Can an account belong to more than one management group, and are mappings effective-dated?

The reference examples differ in grouping vocabulary from some chart-of-accounts examples; what controlled hierarchy is intended?