Month-end close adjustment controls

How the model read it

The observed model has Ledger.SignedAmount, Ledger.IsAdjustment, Calendar support, and a Metrics table. Consultant evidence supports upstream JournalSource and ApprovalStatus. However, ApprovalStatus is not in the audited model and no delivered close-control view or sign-off workflow is evidenced.

Which report page or audience should own the control view?

What exact event and timestamp define reporting-pack sign-off?

How is a manual adjustment identified: JournalSource, IsAdjustment, or a combination?

How the model read it

No Unapproved Adjustment Value implementation or consultant acceptance record is present in current gold. Although the requirement clearly states the intended exclusion, no evidence confirms that a delivered calculation enforces it.

Who is authorised to provide consultant confirmation?

What test cases will demonstrate exclusion of approved adjustments?

Must confirmation be recorded in a test script, deployment approval, or governance register?

How the model read it

A consultant evidence page states that Ledger.JournalSource is available in the governed ledger export at entry grain, but the audited Ledger table has only DateKey, AccountKey, SignedAmount, and IsAdjustment. Thus source support exists while current-model implementation was not observed.

Is JournalSource approved for addition to the target semantic model?

What source values constitute manual journals?

Who owns value-domain governance and mapping changes?

How the model read it

A consultant evidence page states that Ledger.ApprovalStatus is available in the governed ledger export at entry grain, but it was not observed in the audited Ledger table. Source feasibility is supported; implementation in the current model is not.

Is ApprovalStatus approved for addition to the semantic model?

What is the authoritative status domain and case handling?

Is status captured as current state or as-of close cut-off?

How the model read it

The requested measure is not one of the four observed Metrics measures. Current gold contains no supporting object with this qualified name. This means not found within the available discovered landscape, not proof of enterprise-wide absence.

Should this be a new explicit DAX measure in Metrics?

What currency and formatting rules apply?

Must the measure respond to all account and calendar filters?

How the model read it

Consultant evidence describes both upstream attributes as ledger-entry-grain fields and recommends preserving that grain. The audited model does not contain the attributes, and current gold does not establish a unique ledger-entry key or confirm the implemented Ledger table grain, so feasibility is supported but conformity is unverified.

What column or composite key uniquely identifies a ledger entry?

Can one ledger entry have multiple approval history rows?

Will ingestion deduplicate, aggregate, or otherwise change source grain?

How the model read it

The model contains SignedAmount and IsAdjustment, while ApprovalStatus is supported upstream. No exact DAX was available and the requested measure was not observed. The component concepts partially map, but the calculation and treatment of status values remain unimplemented or unverified.

Does 'sum the absolute value' mean SUMX over ABS(SignedAmount) per qualifying entry?

Does 'not approved' include blank, pending, rejected, cancelled, or unknown statuses?

Should reversals and duplicate adjustment entries be handled specially?

How the model read it

Current gold does not identify a ledger-entry key, original-entry URL/reference, drill-through report page, or interaction. Existing Ledger columns are insufficient to establish traceability to an individual original entry.

What is the authoritative ledger-entry identifier?

Should drill-through remain inside Power BI or deep-link to the finance system?

Which entry attributes may be displayed, considering access and sensitivity?

How the model read it

The evidence page supports the existence of a governed finance ledger export and recommends reconciliation, but no completed closed-month reconciliation, tolerance, results, or acceptance sign-off is recorded. The control is plausible but not established.

Which export, version, and owner are authoritative?

Which closed month will be used for acceptance?

Must reconciliation cover row counts, qualifying entry IDs, values, or all three?

What tolerance and sign-off evidence are required?

How the model read it

Current gold notes that late approval changes and refresh behaviour need documentation, but it provides no explicit definition of late approval. The required definition is therefore not found in the available discovered landscape.

Is an approval late when it occurs after month end, close lock, export extraction, refresh, or pack sign-off?

Should late approvals restate the closed-month result or remain visible as subsequent changes?

Which timestamp and time zone are authoritative?