Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.

Step 09 · Outcomes, contribution and finance

Goal. Outcome records, the opt-in contribution workflow, invoices and settlement reconciliation in the operations console.

Blueprint delivery stage: Stage 3 (Delivery-Options-Comparison). Blueprint Stage 3 exit: a synthetic company completes the end-to-end journey including a payment decline.

Former 1.3 name: DG membership tool and metadata. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-09 label stay valid.

Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.

Prerequisites

Steps 01, 02, 03, 04, 05, 06, 07, 08 as needed by the table in Dependency-and-Regression-Table; the strict prerequisite is the previous step’s exit evidence. Policy-independent scaffolding may start after the overall start conditions; decision-dependent behaviour and its final oracle stay blocked until the named authority decides. Proposed defaults are recommendations, never prerequisites. Blocked decisions: GL05-staged, Q16.

Changes (illustrative, not a final schema)

Sources: Blueprint pages cited per item (GGA-Requirement-Register).

Build items:

• Outcomes owned by the reporting company; company-confirmed and partner-reported kept apart; only an authorised owner confirms value (pp. 2, 8, 14)
• Versioned contribution offer showing amount, approved tax treatment, period basis and terms version before consent (p. 8)
• Opt-in creates a finance task; finance approves bill-to and total before an invoice; no automatic invoice (pp. 8, 14)
• Settlement by verified bank receipt or verified webhook; unique settlement reference; one 12-calendar-month term from the settlement date; no overlapping terms (pp. 8, 15)
• Voids, refunds and corrections as finance actions with reasons; partial, disputed or mismatched payments stay finance exceptions (pp. 8, 15)
• Renewal needs a fresh decision; never auto-charge or extend; declining leaves data-based eligibility unchanged (pp. 8, 16)
• Money in minor units with explicit currency; a payment gateway is optional (pp. 8, 13)

Expected outputs and invariants

Contribution status never changes eligibility; a partner-reported deal creates no invoice; a duplicate payment creates no second term.

Tests-first subset

Primary scenarios of this step (write these tests first): T20, DG05, DG14, DG15, DG16, DG19, GS14-staged, GS22-staged, GS23-staged, GS24-staged.

Assertions to write first: new GGA scenarios GS14-staged, GS22-staged, GS23-staged, GS24-staged. Legacy scenarios whose primary step is this one: T20, DG05, DG14, DG15, DG16, DG19. Each follows its replacing GS scenario; the 1.3 text is history (Scenario-Dispositions).

Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Blocked by that decision; no oracle is invented.

Deferred integration checks

Scenarios whose primary step is this one but whose full variants need later components:

• None: the scenarios of this step can be completed here.

Follow-up verification brought here

Scenarios (of any step) that can only be completed or rechecked once this step exists:

• GS13-staged: Replayed jobs must not duplicate grants (06) or invoices and terms (09).
• GS17-staged: Routes are added in 04, 06 and 09; extend the matrix each time.
• GS29-staged: Introduction progress (06) and contribution status (09).

Decisions GGA must settle (dependent behaviour stays blocked until the named authority decides)

GL05-staged, Q16

Exit evidence

A synthetic company completes the journey from confirmed value to a dated term, and separately a payment decline (the Blueprint’s Stage 3 exit); GS14, GS22, GS23 and GS24 verified in part.

Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).

Navigation: Step-08-Daily-Tracking-Views ← this step → Step-10-Hardening-and-Operations · Implementation-Order-Overview