Phase Two Power BI Delivery Scope

1. Purpose

This engagement will address the requirements that were not found, or were only partly evidenced, within the discovered Power BI landscape following the data readiness assessment.

The proposed delivery is organised into three evidence-based areas:

1. Finance model enrichment for management accountability and transaction-currency analysis.
2. Customer and sales-order modelling and measures.
3. Month-end close controls for unapproved manual adjustments.

The scope does not include rebuilding requirements already matched to objects in the current gold boundary. Those existing objects remain dependencies where unanswered questions about their business rules, values or calculations affect the proposed work.

No effort estimate, duration, delivery date, resource model or commercial rate is stated because none was included in the evidence bundle.

2. Decision basis and status of findings

The following acceptance rule governs this scope:

• Where a named consultant recorded an explicit disposition, that decision governs the item.
• Where no consultant decision was recorded, the model finding is carried forward unchanged as the working position.
• An effective disposition such as confirmed_gap does not mean that a consultant confirmed it. Its authority is determined by the separate basis field.

For this evidence bundle:

• No scope-bearing item has a consultant decision.
• All 45 scope-bearing items are carried on unreviewed model findings.
• Of those items, 21 are proposed work items.
• Two proposed work items are weak-signal assumptions based on possible or ambiguous evidence.
• The month-end close requirement was authored by a consultant on the client’s behalf, but the ten individual comparison findings against it remain model-unreviewed.

The implications are set out in the assumption register in section 6.

3. Scope boundary

The assessment compared requirements with the current promoted gold wiki, build wiki_7c268dbf7f8b78844080cae53f6f0a0e. That wiki is bounded by what the Power BI audit could access.

Accordingly:

• “Not found” means not found within the discovered landscape. It is not proof that the object or capability is absent elsewhere in the client’s estate.
• Before constructing an item classified as not found, the client must identify any candidate source, semantic model, measure, report or governed artefact that may already satisfy it.
• If an existing asset is identified, it will be assessed against the stated requirement. A conforming asset will be reused rather than duplicated. A partially conforming asset may require adaptation. The affected deliverable and acceptance evidence must then be updated before implementation proceeds.
• Workbook evidence consists of literal text, workbook structure, formulas and declared metadata. Ordinary numeric, date and Boolean cell values were excluded from the assessment.
• Stored formulas show intended or prototype logic. They do not prove successful recalculation, current cached results or production correctness.
• The client-supplied workbooks describe fictional or synthetic examples. They support design intent but do not constitute production source data, reconciliation evidence or proof of readiness.
• Nothing in this scope states that any target object, report, refresh process or control has already been built, deployed, refreshed or adopted.

4. Deliverables

4.1 Finance model enrichment

Business outcome

Finance requires additional classification and transaction attributes to:

• assign ledger activity to operating areas;
• analyse transactions by transaction currency; and
• roll accounts into governed management reporting groups.

These needs were declared in TargetArchitecture_Partial.xlsx and were not found in the audited Account and Ledger inventories.

Proposed delivery

Acceptance criteria

This work area will be accepted when:

1. Ledger.CostCentre, Ledger.CurrencyCode and Account.AccountGroup are present in the agreed target semantic model with the agreed names and data types.
2. CostCentre and CurrencyCode retain the agreed ledger posting grain and do not introduce unintended aggregation or duplication.
3. The cost-centre source, hierarchy owner and effective-dating treatment are documented and reflected in the implemented design.
4. The currency design records whether analysis uses transaction amount, reporting amount, exchange rates and a Currency dimension, and the implementation conforms to that decision.
5. AccountGroup values reconcile to the approved mapping source, including the agreed handling of multiple group membership and effective dating.
6. Test evidence demonstrates that each attribute can filter or group the relevant ledger or account records as intended.
7. Any equivalent assets found outside the current gold boundary are assessed and either reused, adapted or rejected with the reason recorded.

4.2 Customer and sales-order model

Business outcome

The client-supplied sales architecture requires customer accountability, customer segmentation, sales-order analysis, gross order intake and customer lifetime value. None of the eight declared customer, sales-order or sales-measure requirements were found in the finance-led discovered landscape.

Proposed delivery

The workbook does not explicitly declare a SalesOrder.CustomerIdentifier field or a customer-to-order relationship, although the sales-order content implies that such a linkage is required. The client must approve the necessary linkage before customer lifetime value can be implemented. The precise key and relationship are not committed as named deliverables until that requirement is resolved.

Acceptance criteria

This work area will be accepted when:

1. The eight qualified objects listed above are available in the agreed target semantic model.
2. Customer.CustomerIdentifier is demonstrated to be stable and unique under the client-approved key rule.
3. The approved customer-segment domain and history treatment are documented and enforced by the model design.
4. Relationship-owner handling covers the approved combination of owner identifiers, names, reassignment history, vacancies and shared ownership.
5. SalesOrder.OrderIdentifier supports the agreed treatment of revisions, split orders, cancellations and multiple source systems or legal entities.
6. SalesOrder.OrderGrossValue implements the approved treatment of tax, freight, discounts, returns, cancellations, amendments and currency.
7. SalesOrder.SalesChannel uses the approved governed domain and attribution rule.
8. A client-approved customer-to-order linkage is in place before customer-level order measures are accepted.
9. SalesMetrics.Customer Lifetime Value reproduces the approved calculation across agreed test cases. The illustrative 3.2 frequency multiplier in the workbook is not accepted as a production rule unless the client explicitly approves it.
10. SalesMetrics.Gross Order Intake reconciles to approved test orders under the agreed booking event, reporting date, cancellation, amendment and restatement rules.
11. The current finance measure Metrics.Actual Revenue is not treated as equivalent to gross booked order intake without calculation and semantic evidence.
12. Any candidate customer, order or sales assets found elsewhere in the estate are assessed before duplicate construction begins.

4.3 Month-end close adjustment controls

Business outcome

Finance requires a monthly control view that identifies unapproved manual adjustments before the reporting pack is signed off. Users must be able to understand the exception value and trace it to the original ledger entries.

This requirement was authored by the Synthetic Consultant on the client’s behalf. Consultant-added evidence states that JournalSource and ApprovalStatus are available in the governed ledger export at ledger-entry grain. The assessment did not find those fields in the audited semantic model and did not find the requested measure, control view, drill-through or acceptance evidence.

Proposed delivery

Required calculation rule

Subject to resolution of the status and adjustment definitions, the measure is to sum the absolute value of each qualifying adjustment entry where approval status is not approved.

The following details must be approved before the calculation is finalised:

• whether the calculation is an entry-level iteration over ABS(Ledger.SignedAmount);
• whether manual adjustments are identified through JournalSource, IsAdjustment, or both;
• which statuses count as “not approved”;
• treatment of blank, pending, rejected, cancelled and unknown statuses;
• treatment of reversals and duplicates;
• the applicable currency and formatting;
• required account and calendar filter behaviour.

Acceptance criteria

This work area will be accepted when:

1. Ledger.JournalSource and Ledger.ApprovalStatus are present in the agreed target semantic model and trace to the governed ledger export.
2. The attributes remain at ledger-entry grain, with a documented unique entry key or composite key.
3. The status domain, case handling and as-of treatment are documented and implemented.
4. The rule identifying a manual adjustment is documented and applied consistently.
5. Metrics.Unapproved Adjustment Value calculates the sum of absolute values for qualifying entries and excludes entries with the approved status.
6. Approved, unapproved, blank-status, reversal and duplicate scenarios are covered by agreed test cases.
7. The control view identifies the qualifying entries and their exception value for the agreed monthly close audience.
8. The reporting-pack sign-off event and timestamp are explicitly defined.
9. Users can drill through to the original entry using the approved traceability approach and only approved entry attributes are displayed.
10. The late-approval definition states:
    • the event after which approval is late;
    • the authoritative timestamp and time zone; and
    • whether a later approval restates the closed-month result or remains visible as a subsequent change.
11. For the selected closed month, reconciliation evidence compares the agreed combination of row counts, qualifying entry identifiers and values with the specified governed ledger export, using the client-approved tolerance.
12. An authorised consultant records confirmation, in the agreed acceptance artefact, that approved adjustments are excluded from the exception value.

5. Existing matched objects

The assessment carried forward 24 model-unreviewed findings as confirmed matches. They are not proposed construction work under this scope.

These include existing finance objects such as:

• Account.AccountKey
• Account.AccountName
• Account.AccountType
• Calendar.DateKey
• Calendar.Date
• Calendar.FiscalMonth
• Ledger.DateKey
• Ledger.AccountKey
• Ledger.SignedAmount
• Ledger.IsAdjustment
• Metrics.Actual Net
• Metrics.Actual Revenue
• Metrics.Budget Net
• Metrics.Net Variance

Their existence was evidenced by object names, types and, where applicable, relationships. Exact production DAX, value-level conformance and several business rules were not available. These objects will not be assumed semantically correct where their behaviour affects a scoped deliverable.

6. Assumption register

6.1 Authority of scoped findings

6.2 Proposed work carried on model findings

6.3 Weak-signal assumptions

The following are the most likely scope items to change because the underlying comparison was classified as a possible or ambiguous match.

These two items require explicit confirmation before their related design and acceptance approach is treated as fixed.

7. Dependencies and decisions required

Unanswered model questions are delivery dependencies. The client must provide decisions, authoritative owners or evidence for the following matters.

7.1 Cross-cutting finance model decisions

7.2 Finance enrichment decisions

7.3 Customer and sales decisions

7.4 Month-end close-control decisions

7.5 Context-only decisions that could change scope

The Management P&L sheet in TargetArchitecture_Partial.xlsx was explicitly treated as contextual rather than authoritative. The following are not included deliverables unless the client or consultant confirms them as requirements:

• Actual Expenses
• Budget Revenue
• Budget Expenses

A decision is also required on their approved DAX, budget source and account-classification approach if they are brought into scope.

8. Client responsibilities

The client is responsible for:

1. Identifying authoritative business and technical owners for Finance, Chart of Accounts, Cost Centre, Currency, CRM customer data, sales orders, journal approvals and the month-end close process.
2. Providing access to the approved source systems, exports, semantic models and reports required to confirm whether not-found items already exist elsewhere in the estate.
3. Supplying the governed ledger export containing JournalSource and ApprovalStatus, including the ledger-entry identifier and data needed for the selected closed-month reconciliation.
4. Supplying or approving the source and mapping rules for cost centres, currencies, account groups, customer segments, relationship owners and sales channels.
5. Defining customer and sales-order keys, grain, relationships and history requirements.
6. Approving the production definitions for customer lifetime value and gross order intake.
7. Resolving the dependencies and decisions in section 7 before the affected design or calculation is finalised.
8. Selecting the closed month and reconciliation tolerance for month-end control acceptance.
9. Defining the reporting-pack sign-off event and late-approval rule.
10. Confirming which ledger-entry attributes may be exposed through drill-through and any applicable access or sensitivity restrictions.
11. Nominating business and consultant approvers and providing timely acceptance decisions.
12. Reviewing the assumption register and either confirming the model-unreviewed positions or supplying corrections before they become fixed implementation commitments.

9. Exclusions

The following are excluded unless separately approved through an updated scope:

• Rebuilding the 24 objects classified as matched.
• Production implementation of Actual Expenses, Budget Revenue or Budget Expenses, which were context-only observations.
• Treating workbook sample values, prototype formulas or formula results as production source data.
• Reusing existing finance measures as sales or control measures without exact DAX and semantic evidence.
• Source-system remediation not required to expose the declared target objects.
• Additional customer, order, currency, exchange-rate, budget or approval-history objects that are not confirmed through the decisions in section 7.
• A customer-to-order field or relationship whose key and requirement have not been approved.
• Report pages other than the declared month-end close-control view.
• Refresh architecture, gateway configuration, deployment pipelines, workspace design or operational support arrangements. No supporting requirement was included in the evidence bundle.
• Row-level security, information-protection design or broader security governance. The workbook inspection does not establish those requirements.
• Training, communications, user adoption or organisational change activities.
• Evidence that any target has already been deployed, refreshed or adopted.
• Estate-wide certification that an item does not exist. The assessment boundary cannot support such a claim.

10. Scope change conditions

The scope must be reviewed before implementation proceeds where:

• an item classified as not found is located elsewhere in the client’s estate;
• a consultant changes a model-unreviewed disposition;
• a weak-signal assumption is disproved;
• the client confirms additional Management P&L measures as production requirements;
• transaction-currency analysis requires additional amount or exchange-rate fields;
• customer lifetime value requires undeclared customer-order structures;
• approval history changes the required ledger-entry grain;
• reconciliation requires data, periods or tolerances materially different from the stated acceptance approach; or
• a required source, key, mapping, business definition or approver cannot be supplied.

A conforming existing asset will be reused rather than duplicated. A non-conforming asset will not be treated as satisfying the requirement solely because it has a similar name.

Appendix A: Inputs used to define this scope

A.1 Client-supplied spreadsheets

Compared spreadsheet snapshots

These client-supplied spreadsheets produced the scope-bearing workbook findings.

Earlier not-compared intake snapshots

The evidence bundle also contained earlier records of the same client-supplied filenames. They were not compared with current gold and did not produce scope-bearing findings.

A.2 Consultant-authored requirements

These requirements were authored by the consultant on the client’s behalf. They carry consultant authority rather than being direct client-authored spreadsheet evidence.

The requirement calls for a monthly close-control view, Ledger.JournalSource, Ledger.ApprovalStatus, Metrics.Unapproved Adjustment Value, ledger-entry grain, drill-through, closed-month reconciliation, a late-approval definition and consultant confirmation that approved adjustments are excluded.

A.3 Consultant-added evidence and steering

The following consultant evidence was added to the knowledge base during the assessment and shaped what the comparison could see.

No separate consultant steering entries were included in the evidence bundle.

How this document was produced

The narrative above was written by a language model from a fixed evidence bundle. The figures in this section are written by the application itself and are not model output.

• Document: Phase Two Scope / Statement of Work (report_e247b8a61cb9093bbe19e7925dfee3c1)
• Generated: 2026-07-31T04:55:20.223Z
• Evidence bundle: ev_sha256_28dcbf4ec18a2fb582e344dec6d0dbfb0c296b0923bca4c51a23cac8f0383084 (fingerprint a18c3c7ca716e20f)
• Prompt: scope-sow-report.md (cdf8932d648c7d0d)
• Model: codex
• Current gold build: wiki_7c268dbf7f8b78844080cae53f6f0a0e · 11 pages
• Data profile: synthetic

Basis of the items in this document

• Items assessed: 45
• Carrying an explicit consultant decision: 0
• Carried on the model's unreviewed finding: 45, of which 2 rest on a possible or ambiguous match

Where a consultant decision exists it governs the item. Where none exists the model's finding has been carried forward unchanged; such items are the working position, not an agreed one, and may move when reviewed.