# 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

| Deliverable | Business purpose | Technical scope | Evidence |
|---|---|---|---|
| Cost-centre modelling | Allow ledger activity to be assigned to an operating area for accountability and analysis. | Add `Ledger.CostCentre` at an agreed grain, or implement an agreed cost-centre dimensional design if a fact-table code is insufficient. Confirm hierarchy ownership and effective-dating treatment before finalising the design. | `TargetArchitecture_Partial.xlsx`, item TF-11; `Target Fields!A12:J12`; `Ledger Sample!E3:E15`; `Reference Data!A1:A4` |
| Transaction-currency modelling | Allow users to distinguish ledger postings by transaction currency. | Add `Ledger.CurrencyCode` using an agreed ISO code source. Determine whether a governed currency dimension, transaction amount, reporting amount and exchange-rate attributes are required to make the analysis meaningful. | `TargetArchitecture_Partial.xlsx`, item TF-12; `Target Fields!A13:J13`; `Ledger Sample!F3:F15`; `Reference Data!C1:C4` |
| Management account grouping | Allow accounts to roll up into an agreed management reporting hierarchy. | Add `Account.AccountGroup` and implement the approved mapping source, hierarchy and effective-dating approach. | `TargetArchitecture_Partial.xlsx`, item TF-13; `Target Fields!A14:J14`; `Chart of Accounts!D3:D13`; `Reference Data!B1:B4` |

#### 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

| Deliverable | Business purpose | Technical scope | Evidence |
|---|---|---|---|
| Customer identity | Identify customers consistently across the commercial data domain. | Create `Customer.CustomerIdentifier` using the approved stable and unique customer key. Determine whether enterprise and source-system identifiers must both be retained. | `TargetArchitecture_CompleteMiss.xlsx`, item TF-01; `Target Fields!A2:J2` |
| Customer segmentation | Analyse customers using governed commercial segments. | Create `Customer.CustomerSegment` using the approved segment domain and agreed historical treatment. | Item TF-02; `Target Fields!A3:J3`; `Reference Data!A2:C4` |
| Relationship ownership | Attribute customers to accountable relationship owners. | Create `Customer.RelationshipOwner`, including owner identifiers or display names as agreed, and define treatment for reassignment, vacancy and shared ownership. | Item TF-03; `Target Fields!A4:J4` |
| Sales-order identity | Identify commercial orders at an agreed, stable grain. | Create `SalesOrder.OrderIdentifier` and document how revisions, splits, cancellations and multiple systems or legal entities affect uniqueness. | Item TF-04; `Target Fields!A5:J5` |
| Gross order value | Report the value booked at order grain before the agreed deductions. | Create `SalesOrder.OrderGrossValue` with approved treatment of discounts, tax, freight, currency, cancellations, returns and amendments. | Item TF-05; `Target Fields!A6:J6`; `Sales Orders!A1:D3` |
| Sales channel | Analyse orders by acquisition or sales channel. | Create `SalesOrder.SalesChannel` using the approved channel domain and attribution rule. | Item TF-06; `Target Fields!A7:J7`; `Reference Data!A5:C7` |
| Customer lifetime value | Provide a governed customer-value measure rather than rely on an illustrative multiplier. | Create `SalesMetrics.Customer Lifetime Value` using an approved forecast horizon, value basis, expected-order-frequency method and treatment of churn, returns, discounts and tenure. | Item TF-07; `Target Fields!A8:J8`; `Sales KPI Prototype!A5:C5`; `Sales KPI Prototype!B5` |
| Gross order intake | Measure gross booked order value using the agreed booking event and reporting date. | Create `SalesMetrics.Gross Order Intake` as the approved aggregation of order gross value, including agreed treatment of cancellations, amendments, tax, discounts and currency conversion. | Item TF-08; `Target Fields!A9:J9`; `Sales KPI Prototype!A4:C4`; `Sales KPI Prototype!B4` |

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

| Deliverable | Business purpose | Technical scope | Evidence |
|---|---|---|---|
| Journal source | Distinguish manual journals from other ledger activity. | Add `Ledger.JournalSource` using the governed ledger export and approved source-value mapping. | Consultant requirement item R2; `Consultant Requirement!A5`; consultant evidence `fde-finance.journal-controls` |
| Approval status | Identify adjustments that have not been approved by the applicable close cut-off. | Add `Ledger.ApprovalStatus` using an approved status domain and agreed current-state or as-of-cut-off treatment. | Item R3; `Consultant Requirement!A5`; consultant evidence `fde-finance.journal-controls` |
| Ledger-entry grain preservation | Prevent aggregation or duplication from obscuring individual adjustment entries. | Preserve `JournalSource` and `ApprovalStatus` at ledger-entry grain and establish the identifier or composite key used to distinguish entries. | Item R5; `Consultant Requirement!A5`; weak signal |
| Unapproved adjustment measure | Quantify the value of adjustment entries that are not approved. | Create `Metrics.Unapproved Adjustment Value` using the approved treatment of absolute values, adjustment identification and non-approved statuses. | Items R4 and R6; `Consultant Requirement!A5` |
| Monthly close-control view | Give Finance a usable pre-sign-off exception view. | Create the agreed Power BI control view showing unapproved manual adjustments for the applicable month and cut-off. Confirm its audience and report location. | Item R1; `Consultant Requirement!A5` |
| Original-entry drill-through | Allow an exception to be traced to its underlying ledger entry. | Provide drill-through using the authoritative ledger-entry identifier, either within Power BI or through an approved finance-system link. Display only approved entry attributes. | Item R7; `Consultant Requirement!A5` |
| Late-approval definition | Establish how approvals occurring after the close cut-off are treated. | Record the approved event, timestamp, time zone and restatement behaviour that define a late approval. | Item R9; `Consultant Requirement!A5` |
| Closed-month reconciliation | Demonstrate that the control agrees with the governed ledger export. | Reconcile the control for an agreed closed month using the agreed export version, row or entry matching, value checks, tolerance and sign-off evidence. | Item R8; `Consultant Requirement!A5`; consultant evidence `fde-finance.journal-controls`; weak signal |
| Consultant confirmation | Confirm that approved adjustments do not contribute to the exception value. | Execute agreed test cases and record confirmation in the approved acceptance artefact. | Item R10; `Consultant Requirement!A5` |

#### 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

| Dependency or decision | Affected scope | Consequence if unresolved |
|---|---|---|
| Finance source contains cost centre at the required grain | Cost-centre modelling | The attribute cannot be implemented as specified without an alternative source or revised design. |
| Approved cost-centre and account-group governance | Finance attributes | Hierarchies and mappings cannot be finalised or accepted. |
| Transaction-currency source and analytical requirements | Currency modelling | `CurrencyCode` may be insufficient without additional amounts and exchange-rate data. |
| Governed customer and order sources | Customer and sales domain | The requested columns and measures cannot be populated or tested. |
| Approved customer-to-order linkage | Customer lifetime value | CLV cannot be calculated reliably at customer grain. |
| Approved CLV methodology | Customer lifetime value | The spreadsheet’s illustrative multiplier cannot be promoted as a production rule. |
| Approved booking event and restatement rules | Gross order intake | The measure cannot be defined consistently across periods. |
| Governed ledger export and entry identifier | Month-end control | Entry-grain preservation, drill-through and reconciliation cannot be completed. |
| Approval-status domain and cut-off treatment | Month-end control | The exception population and measure cannot be determined. |
| Definition of manual adjustment | Month-end control | The control cannot reliably identify its target population. |
| Reporting-pack sign-off event and late-approval rule | Month-end control | The control cut-off and late-change behaviour remain undefined. |
| Reconciliation month, tolerance and evidence format | Month-end control acceptance | Evidence-based acceptance cannot be completed. |
| Authorised consultant confirmer | Month-end control acceptance | The requirement for consultant confirmation remains unmet. |
| Exact existing measure definitions where reused | Existing finance measures | A matching measure name cannot establish semantic equivalence. |
| Discovery of an apparently missing object elsewhere in the estate | All gap-based work | The object will be assessed for reuse. Duplicate construction is not assumed, and any material scope effect must be agreed. |

### 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

| Basis | Scope-bearing items | Proposed work items | Treatment |
|---|---:|---:|---|
| Consultant decision | 0 | 0 | No named consultant disposition was recorded. |
| Model unreviewed | 45 | 21 | Model findings are carried forward unchanged as the working scope position. |

### 7.2 Proposed work assumptions

Every item below is scoped on an unreviewed model finding.

| Input and item | Effective disposition | Scope assumption | Weak signal |
|---|---|---|---|
| `TargetArchitecture_Partial.xlsx` TF-11 | Confirmed gap | `Ledger.CostCentre` was not found in current gold and requires delivery work unless an existing estate object is identified. | No |
| `TargetArchitecture_Partial.xlsx` TF-12 | Confirmed gap | `Ledger.CurrencyCode` was not found in current gold and requires delivery work unless an existing estate object is identified. | No |
| `TargetArchitecture_Partial.xlsx` TF-13 | Confirmed gap | `Account.AccountGroup` was not found in current gold and requires delivery work unless an existing estate object is identified. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-01 | Confirmed gap | `Customer.CustomerIdentifier` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-02 | Confirmed gap | `Customer.CustomerSegment` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-03 | Confirmed gap | `Customer.RelationshipOwner` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-04 | Confirmed gap | `SalesOrder.OrderIdentifier` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-05 | Confirmed gap | `SalesOrder.OrderGrossValue` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-06 | Confirmed gap | `SalesOrder.SalesChannel` was not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-07 | Confirmed gap | `SalesMetrics.Customer Lifetime Value` and its supporting structure were not found in current gold. | No |
| `TargetArchitecture_CompleteMiss.xlsx` TF-08 | Confirmed gap | `SalesMetrics.Gross Order Intake` was not found in current gold. | No |
| Month-end controls R1 | Confirmed partial | Supporting finance objects exist, but no delivered close-control view or sign-off workflow was evidenced. | No |
| Month-end controls R2 | Confirmed partial | `JournalSource` is stated to exist upstream but was not observed in the audited semantic model. | No |
| Month-end controls R3 | Confirmed partial | `ApprovalStatus` is stated to exist upstream but was not observed in the audited semantic model. | No |
| Month-end controls R4 | Confirmed gap | `Metrics.Unapproved Adjustment Value` was not found in current gold. | No |
| Month-end controls R5 | Confirmed partial | Entry-grain source support is possible, but the audited model does not establish the entry key or current ledger grain. | **Yes** |
| Month-end controls R6 | Confirmed partial | Component concepts exist, but the required exception calculation is not implemented or verified. | No |
| Month-end controls R7 | Confirmed gap | No original-entry identifier, link or drill-through implementation was found. | No |
| Month-end controls R8 | Confirmed partial | A governed export is supported by consultant evidence, but completed closed-month reconciliation was not evidenced. | **Yes** |
| Month-end controls R9 | Confirmed gap | An explicit definition of late approval was not found. | No |
| Month-end controls R10 | Confirmed gap | No implementation or consultant acceptance record confirms exclusion of approved adjustments. | No |

### 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

| Spreadsheet | Sheets |
|---|---|
| `TargetArchitecture_Partial.xlsx` | `Read Me`; `Target Fields`; `Chart of Accounts`; `Fiscal Calendar`; `Ledger Sample`; `Management P&L`; `Reference Data` (hidden); `Validation` |
| `TargetArchitecture_Match.xlsx` | `Read Me`; `Target Fields`; `Chart of Accounts`; `Fiscal Calendar`; `Ledger Sample`; `Management P&L`; `Reference Data` (hidden); `Validation` |
| `TargetArchitecture_CompleteMiss.xlsx` | `Read Me`; `Target Fields`; `Customer Sample`; `Sales Orders`; `Sales KPI Prototype`; `Reference Data` (hidden); `Validation` |

## 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.

| Requirement | Contributor | Source representation |
|---|---|---|
| `Month-end close adjustment controls` | Synthetic Consultant | Consultant-authored virtual workbook, sheet `Consultant Requirement` |

## C. Consultant-added evidence and steering

| Type | Title | Contributor |
|---|---|---|
| Consultant evidence added to current gold | `Synthetic journal control attributes` | Synthetic Consultant |

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.