# Power BI Data Readiness Assessment

## Executive position

The discovered estate provides a credible core finance foundation, but it does not yet support the full reporting and control agenda assessed.

Across the four compared inputs, there are **45 scope-bearing requirement assessments**:

| Current position | Requirements | What it means |
|---|---:|---|
| Found directly | 24 | The requested object is present in the discovered landscape, although some business rules and calculations still require validation. |
| Partly supported | 6 | Relevant data or components appear to exist, but the requested capability has not been fully evidenced. |
| Not found | 15 | The requested object or capability was not identified within the discovered landscape. |
| **Total** | **45** |  |

This leaves **21 assessments requiring delivery or resolution**, comprising the 15 not found and the 6 partly supported.

The position is uneven:

- **Core finance data is the strongest area.** One client spreadsheet is rated **Ready**, with all 14 requirements found. A second is **Largely ready**, with 10 of 13 requirements found.
- **Customer and sales reporting has material gaps.** None of its eight requirements was found.
- **The month-end adjustment control also has material gaps.** Six requirements have some supporting evidence, but four were not found and no requirement is a direct match to a delivered control.
- The evidence supports **targeted gap closure rather than rebuilding the finance foundation wholesale**.

There is an important decision caveat. **None of the 45 assessments has been confirmed by a consultant.** All are unreviewed model findings and therefore represent the current working position, not agreed fact. Two of the partly supported findings are specifically marked as weak-signal assumptions.

“Not found” means not found in the current audited landscape, which was limited to what the Power BI audit could access. It does not prove that the client does not hold the data elsewhere. Any funding decision should therefore distinguish between locating and confirming existing data, and building genuinely new capability.

## Readiness by reporting area

| Input and reporting area | Readiness band | Assessment | Executive implication |
|---|---|---|---|
| `TargetArchitecture_Match.xlsx`, core finance model and measures | **Ready** | 14 direct matches | The requested account, calendar and ledger structure, plus four finance measures, was found. Remaining questions are validation checks, not identified implementation gaps. |
| `TargetArchitecture_Partial.xlsx`, extended finance analysis | **Largely ready** | 10 direct matches; 3 not found | The core model is present, but cost-centre accountability, transaction-currency analysis and the requested account management roll-up are not supported by objects found in the current landscape. |
| `TargetArchitecture_CompleteMiss.xlsx`, customer and sales reporting | **Material gaps** | 8 not found | No supporting customer, sales-order or requested sales-metric objects were found in the current finance-ledger model. |
| Month-end close adjustment controls | **Material gaps** | 6 partly supported; 4 not found | Some source and model components exist, but the control view, calculation, traceability and acceptance evidence have not been established. |

The 45 assessments are requirement instances across the four inputs. Some core finance requirements recur in more than one spreadsheet, so the total should not be interpreted as 45 unique data objects.

## What is already present

The evidence identifies a substantial existing finance structure:

- Account key, name and type.
- Calendar date key, date and fiscal month.
- Ledger date and account keys, including active relationships to the calendar and account structures.
- Signed ledger amount and adjustment indicator.
- Measures named **Actual Net**, **Actual Revenue**, **Budget Net** and **Net Variance**.

All 14 requirements in the fully matched finance spreadsheet map directly to current objects. This is the clearest area in which existing capability should be retained and validated rather than treated as missing.

However, direct matching establishes that the named objects exist. It does not establish that all underlying business rules and calculations are correct. Exact calculation expressions for the four observed measures were not available, and ordinary numeric, date and Boolean cell values were excluded from the evidence. Reconciliation and value-level conformity therefore remain unproven.

## Where investment is required

### 1. Extended finance analysis

Three required finance attributes were not found:

| Requirement not found | Reporting consequence if unresolved |
|---|---|
| `Ledger.CostCentre` | The requested operating-area accountability cannot be supported from the objects currently observed. |
| `Ledger.CurrencyCode` | The requested transaction-currency analysis cannot be supported. The requirement also raises unresolved questions about transaction amounts, reporting amounts and exchange-rate treatment. |
| `Account.AccountGroup` | The requested management account roll-up cannot be supported. The authoritative source, ownership and effective-dating rules for the grouping remain unresolved. |

These are specific extensions to an otherwise established finance model. They do not indicate that the whole finance foundation is absent.

### 2. Customer and sales reporting

All eight declared requirements were not found:

- Customer identifier.
- Customer segment.
- Relationship owner.
- Sales-order identifier.
- Gross order value.
- Sales channel.
- Customer Lifetime Value.
- Gross Order Intake.

The current discovered model is finance-ledger based and provides no observed customer or sales-order structure supporting these requirements. Existing finance measures cannot be assumed to be substitutes for booked order value or customer lifetime value.

Leaving this area unresolved means the requested customer segmentation, relationship accountability, order analysis and two sales metrics cannot be produced from the model as currently evidenced.

Before implementation is committed, the business definitions also need to be settled. Open decisions include customer identity, segmentation history, order uniqueness, treatment of cancellations and amendments, channel attribution, currency treatment, and the production definition of Customer Lifetime Value.

### 3. Month-end close adjustment control

The requested control is not evidenced as a completed capability.

There is support for parts of the design:

- `Ledger.SignedAmount` and `Ledger.IsAdjustment` are present.
- Consultant evidence states that `JournalSource` and `ApprovalStatus` are available in the governed ledger export at ledger-entry grain.
- A governed ledger export is available as a potential reconciliation source.

That support does not establish implementation in the current model. The assessment found:

| Control component | Current position |
|---|---|
| Monthly view of unapproved manual adjustments before reporting-pack sign-off | Partly supported, but no delivered view or sign-off workflow was evidenced |
| `Ledger.JournalSource` | Available upstream, but not observed in the current model |
| `Ledger.ApprovalStatus` | Available upstream, but not observed in the current model |
| Preservation of ledger-entry grain | Possible, but no unique entry key or implemented grain was established |
| Exception calculation using absolute adjustment values not approved | Components partly exist, but the calculation was not found or verified |
| `Metrics.Unapproved Adjustment Value` | Not found |
| Drill-through to the original ledger entry | Not found |
| Closed-month reconciliation to the governed ledger export | Possible, but no completed reconciliation or acceptance result was evidenced |
| Explicit definition of late approval | Not found |
| Consultant confirmation that approved adjustments are excluded | Not found |

If these gaps remain open, Finance cannot rely on the assessed landscape to provide the requested pre-sign-off exception view, trace an exception to its original entry, or demonstrate that the control has been reconciled and accepted.

The two weakest assumptions in the overall assessment are within this control: preservation of ledger-entry grain and the feasibility of closed-month reconciliation. Both have supporting indications, but neither is established.

## Validation questions are not implementation gaps

Several items have been found directly but still require confirmation. These should be treated as validation work, not as evidence that the underlying object is absent.

The main validation matters are:

- Whether `AccountType` covers the intended balance-sheet and profit-and-loss classifications.
- Whether `DateKey` follows the required YYYYMMDD encoding and is unique.
- Whether fiscal-month numbering uses July as month one.
- Whether fiscal month should be configured not to summarise by sum.
- Whether signed amounts consistently use the intended reporting currency and sign convention.
- What operational rule classifies a posting as an adjustment.
- Whether the observed finance measures implement the required calculations and filter behaviour.
- What source and grain support the observed Budget Net measure.
- Whether Net Variance is calculated as Actual Net less Budget Net with the intended sign treatment.

These checks matter because the evidence establishes object presence, but not value-level conformity or exact calculation equivalence.

By contrast, the missing cost-centre, currency, account-group, customer, sales-order and control objects are identified implementation or discovery gaps within the assessed boundary.

## Decision required

The evidence supports a staged investment decision:

1. **Retain and validate the existing core finance foundation.**  
   The 24 direct matches should not be treated as net-new build without first resolving their validation questions.

2. **Confirm the 15 not-found items against the wider estate.**  
   This determines which items require source discovery and integration, and which are genuinely new data or reporting capabilities.

3. **Scope the 21 proposed work items as three distinct business packages.**
   - Three extended-finance requirements.
   - Eight customer and sales requirements.
   - Ten month-end close-control requirements, including six with partial support.

4. **Require consultant review before treating the assessment as an agreed baseline.**  
   At present, all 45 findings are assumed working positions and none has an explicit consultant decision.

The overall conclusion is that the finance estate is **partly reusable and materially incomplete**. Core finance reporting has a strong starting point. The principal funding need is to extend that foundation into management analysis, customer and sales reporting, and an evidenced month-end adjustment control.

---

## 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: Data Readiness Report (`report_1bc471977ead224b37410401bd01c2a3`)
- Generated: 2026-07-31T04:52:37.662Z
- Evidence bundle: `ev_sha256_28dcbf4ec18a2fb582e344dec6d0dbfb0c296b0923bca4c51a23cac8f0383084` (fingerprint `a18c3c7ca716e20f`)
- Prompt: `data-readiness-report.md` (`038716a59bbd2076`)
- 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.