Power BI Delivery Engagement Scope

1. Purpose

This engagement will address the business and semantic-model gaps carried forward from the Power BI data readiness assessment.

The proposed work covers three evidence-led areas:

1. finance analysis attributes needed for operating accountability, transaction-currency analysis and management reporting;
2. customer and sales-order data needed for commercial analysis and sales measures; and
3. a month-end control for identifying unapproved manual ledger adjustments before reporting-pack sign-off.

The scope is based only on the supplied evidence bundle. It does not include effort estimates, delivery dates, team composition, day rates or implementation sequencing.

2. Scope basis and acceptance rule

Each assessed item has an effective disposition under the following rule:

• where a named consultant recorded a decision, that decision governs the item;
• where no consultant decision was recorded, the model finding is carried forward unchanged as the working position.

No item in this scope has a consultant decision. All 45 scope-bearing findings, including all 21 proposed work items, are therefore based on unreviewed model findings. Silence has been treated as acceptance for scope preparation, but not as proof that the underlying finding is correct.

Two proposed work items are marked as weak_signal. These depend on possible or ambiguous matches and are particularly liable to change:

• preserving journal control attributes at ledger-entry grain; and
• reconciling the close control to a governed ledger export for a closed month.

The full assumption register appears in section 7.

3. Scope boundary

The assessment compared the requirements with the current gold wiki available to the Power BI audit. The following boundaries apply to this delivery scope:

• “Not found” means not found in the discovered landscape. It does not prove that the object, data or capability is absent elsewhere in the client’s estate.
• If a scoped object is found elsewhere, delivery will assess whether it can be reused or adapted rather than create a duplicate. Any resulting change to deliverables or responsibilities will require agreement before proceeding.
• Workbook evidence consists of literal text, structure, formulas and declared metadata. Ordinary numeric, date and Boolean cell values were excluded.
• Stored formulas evidence design intent or logic, but do not prove successful recalculation or current cached results.
• The supplied spreadsheet records are synthetic and fictional where identified as such. They cannot be used as production reconciliation data.
• Nothing in this scope asserts that any target object, report, refresh path or control has already been built, deployed, refreshed or adopted.

4. Proposed delivery scope

4.1 Finance accountability and analysis attributes

Business gap

The current discovered finance model does not expose three attributes required by the client-supplied target register:

• operating-area accountability through cost centre;
• transaction-currency analysis through currency code; and
• management account roll-up through account group.

Without these attributes, the target model cannot provide the requested cost-centre accountability, transaction-currency segmentation or management account grouping.

Proposed deliverables

Acceptance criteria

This workstream will be accepted when:

1. Ledger.CostCentre, Ledger.CurrencyCode and Account.AccountGroup are present in the agreed target semantic design with the names and business purposes stated in the source register.
2. The client-approved source and owner are recorded for each attribute.
3. Cost-centre grain and the decision between a ledger column and separate dimension are recorded.
4. The approved cost-centre hierarchy and effective-dating treatment are recorded where applicable.
5. The approved currency domain and any required currency relationship, transaction amount, reporting amount and exchange-rate treatment are recorded and implemented where agreed as necessary.
6. The approved account-group vocabulary, mapping rules, hierarchy and effective-dating treatment are recorded.
7. Each implemented attribute can be traced to the agreed source field or governed mapping.
8. Testing demonstrates that the attributes retain the agreed grain and do not introduce unintended duplication of ledger or account records.

4.2 Customer and sales-order analytical domain

Business gap

The discovered landscape is finance-led and contains no observed customer or sales-order domain supporting the requested commercial analysis.

The client-supplied target register requires:

• governed customer identity;
• customer segmentation;
• accountable relationship ownership;
• sales-order identity;
• gross order value;
• sales channel;
• customer lifetime value; and
• gross order intake.

These objects were not found within the current gold boundary. Finance ledger objects and measures are not treated as substitutes because their grain and business meaning differ from customer and booked-order analysis.

Proposed deliverables

The target register does not explicitly declare a SalesOrder.CustomerIdentifier field or a customer-to-order relationship, although the synthetic order sheet implies a linkage. The client must confirm the required linkage before the customer lifetime value design can be completed. This scope does not assume an undeclared relationship design.

Acceptance criteria

This workstream will be accepted when:

1. The six requested columns and two requested measures are present in the agreed target semantic design under their qualified names.
2. The governed customer key is documented and tested for the agreed stability and uniqueness conditions.
3. The relationship between customer and sales-order information is explicitly approved and implemented where required to support the requested measures.
4. Customer segment and sales channel use client-approved value domains.
5. Historical treatment is documented for segment and relationship-owner changes.
6. Order grain and identifier behaviour are documented for revisions, split orders, cancellations and multiple source systems or legal entities.
7. Gross order value has an approved definition covering discounts, tax, freight, currency, cancellations, returns and amendments.
8. Customer lifetime value has an approved calculation definition covering forecast horizon, value basis, expected-order frequency, churn, returns, discounts and tenure.
9. Gross order intake has an approved booking event, reporting date and restatement treatment.
10. Measure test results can be reproduced from the agreed source data and approved definitions. The spreadsheet prototype values and formula results will not be used as production acceptance evidence.

4.3 Month-end close adjustment control

Business gap

Finance requires a monthly close-control view that identifies unapproved manual adjustments before the reporting pack is signed off.

The current discovered model includes ledger amount, adjustment indication and calendar support. Consultant-added evidence also states that journal source and approval status are available in a governed ledger export. However, the audited model does not expose those attributes, the exception measure is not present, and there is no evidenced control view, original-entry drill-through, late-approval definition or completed reconciliation.

Proposed deliverables

Acceptance criteria

This workstream will be accepted when:

1. Ledger.JournalSource and Ledger.ApprovalStatus are present in the agreed semantic design and trace to the governed ledger export.
2. The authoritative status domain and the journal-source values identifying manual journals are documented and approved.
3. An authoritative ledger-entry identifier or composite key has been agreed and used to preserve entry-level traceability.
4. Metrics.Unapproved Adjustment Value calculates the sum of the absolute values of qualifying adjustment entries whose approval status is not approved, using the approved status and adjustment rules.
5. The calculation’s treatment of blank, pending, rejected, cancelled and unknown statuses is documented.
6. Treatment of reversals and duplicate entries is documented and tested.
7. Approved adjustments are excluded from the exception value in the agreed test cases.
8. A monthly control view identifies the qualifying entries and their exception value before the agreed reporting-pack sign-off event.
9. Users can drill through from a control exception to the original ledger entry using the approved traceability method.
10. The definition of a late approval records the applicable event, timestamp, time zone and closed-period restatement behaviour.
11. Reconciliation is completed against the agreed version of the governed ledger export for an agreed closed month.
12. The reconciliation evidence covers the agreed combination of row counts, qualifying entry identifiers and values, within the agreed tolerance.
13. The authorised consultant records confirmation that approved adjustments are excluded from the exception value.

5. Client responsibilities

The client will need to provide the following information, access and decisions before the affected deliverables can be completed.

5.1 Finance data and governance

• Confirm whether cost centre is available in the finance posting source at ledger posting grain.
• Nominate the owner and authoritative source for the cost-centre hierarchy.
• Decide whether cost centre will be held as a ledger column or separate dimension.
• Define any effective-dating requirements for cost-centre and account-group mappings.
• Confirm whether transaction currency is available on every posting.
• Decide whether transaction amount, reporting amount and exchange-rate fields are required.
• Confirm the required currency dimension and code governance.
• Nominate the owner and authoritative source for account-group mappings.
• Approve the account-group vocabulary and rules for multiple or changing group memberships.

5.2 Customer and sales data

• Provide or identify the governed CRM customer master and approved customer key.
• Confirm whether both enterprise and source-system customer identifiers must be retained.
• Approve the customer segment domain and historical treatment.
• Define relationship-owner identifiers, display treatment, reassignment history, vacancies and shared ownership.
• Provide or identify the order-management source and define order uniqueness.
• Define the treatment of order revisions, splits and cancellations.
• Approve the definition of gross order value, including tax, freight, discounts, currency, cancellations, returns and amendments.
• Approve the sales-channel domain and any multi-channel attribution rule.
• Complete the customer-to-order relationship requirement omitted from the authoritative target register.
• Approve the customer lifetime value methodology and all required parameters.
• Approve the gross order intake booking event, reporting date and restatement behaviour.

5.3 Month-end controls

• Approve JournalSource and ApprovalStatus for inclusion in the target semantic model.
• Identify the governed ledger export, its owner and the version to be used.
• Define the journal-source values that constitute a manual adjustment.
• Approve the approval-status domain and case handling.
• Decide whether approval status is current-state or assessed as at the close cut-off.
• Provide or approve the ledger-entry identifier.
• Confirm whether a ledger entry can have multiple approval-history rows.
• Confirm whether ingestion may deduplicate, aggregate or otherwise alter ledger grain.
• Define the reporting-pack sign-off event and timestamp.
• Select the report audience and location for the control view.
• Approve the treatment of blank, pending, rejected, cancelled and unknown approval statuses.
• Approve treatment of reversals and duplicate adjustments.
• Approve the drill-through method and the entry attributes users may see.
• Select the closed month for reconciliation.
• Approve the reconciliation coverage, tolerance and required sign-off evidence.
• Define late approval, including the authoritative timestamp, time zone and restatement behaviour.
• Nominate the consultant authorised to confirm exclusion of approved adjustments and the artefact in which that confirmation must be recorded.

5.4 Existing-model validation decisions

The following discovered objects are treated as matches rather than implementation gaps, but their unanswered questions remain dependencies where the new work relies on them:

• approve the complete AccountType domain, including whether it covers Asset, Liability, Equity, Revenue and Expense;
• confirm Calendar.DateKey uses unique YYYYMMDD values;
• confirm July is fiscal month 1;
• decide whether Calendar.FiscalMonth should use “Summarise by None” rather than “Sum”;
• confirm the production reporting-currency and sign convention for Ledger.SignedAmount;
• define the operational rule for Ledger.IsAdjustment;
• provide or approve the exact DAX and classification rules for Metrics.Actual Net, Metrics.Actual Revenue, Metrics.Budget Net and Metrics.Net Variance where those existing measures interact with the scoped changes; and
• identify the production budget source and grain where budget measures require validation.

6. Dependencies and decision gates

Context-only questions

The Management P&L prototype in TargetArchitecture_Partial.xlsx is contextual and creates no delivery obligation. Before any future expansion based on it, the client would need to decide:

• whether Actual Expenses, Budget Revenue and Budget Expenses are required as production measures;
• the approved DAX definitions and source for budget values; and
• whether revenue and expense classification should use account-number ranges or governed AccountType or AccountGroup mappings.

These decisions do not add those measures to the present scope.

7. Assumption register

7.1 Basis summary

7.2 Proposed work assumptions

Every item below is scoped on an unreviewed model finding.

7.3 Existing-match assumptions

Twenty-four items are carried as confirmed matches on the model’s unreviewed findings. They are not proposed build items in this scope:

• the ten matched finance columns in TargetArchitecture_Partial.xlsx;
• the fourteen matched finance columns and measures in TargetArchitecture_Match.xlsx.

A matching object name and data type do not establish value-level conformance or calculation equivalence. If validation shows that one of these objects does not meet the declared requirement, remediation is not automatically included and must be assessed against the agreed scope.

8. Exclusions

The following are outside this scope because no scope-bearing item supports them:

• the context-only Management P&L prototype and its undeclared Actual Expenses, Budget Revenue and Budget Expenses measures;
• replacement of the existing matched finance objects solely because value-level conformance has not yet been proven;
• implementation based on the contents of files listed as received and not assessed;
• promotion of spreadsheet sample values or cached formula results as production data;
• creation of workbook connections, Power Query content, embedded spreadsheet models, pivots or charts;
• source-system remediation beyond the attributes and definitions required for the scoped semantic objects;
• security, row-level security, access-model or sensitivity design other than deciding which ledger-entry attributes may appear in the close-control drill-through;
• report pages or visuals other than the scoped month-end close-control view;
• additional customer, order, finance or budget objects not named in the proposed deliverables;
• deployment, production refresh scheduling, operational support, user training, adoption activity or benefits realisation;
• redesign of automatic date tables or the broader production date strategy;
• reconciliation using synthetic spreadsheet records; and
• any claim that the resulting deliverables have been built, deployed, refreshed or adopted before evidence-based acceptance has been completed.

9. Overall engagement acceptance

The engagement will be ready for acceptance when:

1. each scoped object is either delivered and tested, or formally removed or changed following discovery of an existing estate capability;
2. each deliverable traces to its cited requirement and workbook evidence;
3. all business definitions and source ownership decisions identified as dependencies have been recorded;
4. the required object names, grains, domains, mappings and calculations have been checked against those approved definitions;
5. the customer and sales measures can be reproduced from the agreed governed sources;
6. the month-end control has passed the closed-month reconciliation and approved-adjustment exclusion tests;
7. the authorised acceptance evidence has been recorded for the month-end control; and
8. unresolved assumptions, including the two weak-signal items, have either been confirmed or reflected in an agreed scope change.

Appendix: Inputs to this scope

A. Client-supplied spreadsheets assessed

B. Consultant-authored requirements

These requirements were authored by the consultant on the client’s behalf and carry consultant authority rather than being client-supplied spreadsheet content.

C. Consultant-added evidence and steering

No separate consultant steering entries were included in the bundle.

D. Received and not assessed

The following were received and inspected in earlier records but were not compared with current gold. They support no scope item:

• TargetArchitecture_Partial.xlsx (5 sheets);
• TargetArchitecture_Match.xlsx (5 sheets);
• TargetArchitecture_CompleteMiss.xlsx (6 sheets).

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_974c9f288efefd7636e505782d1802f7)
• Generated: 2026-07-31T05:03:22.518Z
• Evidence bundle: ev_sha256_a2548f7efa309fbea88ffdcf3ae4482de06fd6d1dbed8780404d6c80f08e9fd6 (fingerprint d1286dc87de686be)
• Prompt: scope-sow-report.md (53b9e9f000b0c651)
• 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.