Commercial Services Delivery Plan

Status: proposed work, aligned with the presentation reviewed on 1 October 2026. The behaviour baseline below is based on repository inspection, not verification of the deployed middleware. A fresh CRM field, layout, relationship, workflow and button inspection on 1 October is recorded in the CRM structure preparation. Unchecked items are implementation work; prepared mappings are not installed changes.

Companion presentation: Peppermint Commercial Performance Tracking. The design reference explains the shared model and reporting principles. This page is the single active delivery plan for that model. Historical records preserve completed migrations and dated inventories; their proposed next steps are reconciled below.

Outcome and scope

Connect what we sell, bill and deliver through the same customer commitment. A Deal records the accepted sale. A Service groups its components. Each Service Line defines the agreed selling values, billing instructions and delivery commitment. Billing Events represent individual charges; native Invoice items preserve what was actually billed and link back to their source.

Deliver the new-deal quote-to-invoice flow as one initial phase, in this order: bring the existing offer editor into a CRM widget, verify Qwilr acceptance, then build the reviewed Service Line and billing handoff. The first widget iteration lets staff prepare a Deal offer and generate or update its Qwilr page. Acceptance verification gates the later work on Service Lines, Billing Events and invoice drafts. Iterate on the complete path with new deals and projects.

Reconciliation follows once that path is proven. Historical invoice matching, existing-customer migrations, ongoing financial reconciliation and broader performance completion do not gate the first new-deal pilot. Source identities, accepted-value checks and duplicate-invoice protection are required from the start so the later reconciliation work has reliable evidence.

Generalise the existing Managed Services Plans module as Services and MSP Invoice Lines as Service Lines in the initial phase. Keep Projects for delivery and Account-owned MSP Seats for dated support entitlement. Service Lines consume the roster through their Service's Account. Consolidate the exploratory Commercial_Services module into Services and retire it after its useful evidence and dependencies have been transferred. It is not a second permanent parent or a required record for new deals.

Broader Desk, onboarding and MSP operational improvements follow this work. Retiring Delivery Models or Deal stages, expanding Power BI, and rebuilding the wider unsigned sales pipeline remain outside this plan unless separately scoped. Proposal Lines and the widget's quote preparation are within the initial scope.

Universal module structure

Business module	Implementation decision
Services	Reuse the existing `Managed_Services_Plans` module; rename its display to Client Services and its API name to `Client_Services` in a coordinated integration cutover. Generalise its fields and validation; preserve module and record IDs.
Service Lines	Reuse the existing `MSP_Invoice_Lines` module; rename its display to Service Lines and its API name to `Service_Lines` in the same cutover. Reuse its existing parent relationship and preserve module and line IDs.
Proposal Lines	Proposed Deal-owned terms and revisions used to generate Qwilr; accepted selections map to Service Lines.
Billing Events	New records for individual charges, linked to the source Service Line and invoice item.
Invoices / Invoiced Items	Reuse native documents and items, retaining financial snapshots and source IDs.
MSP Seats / Projects	MSP Seats belong to Accounts and Contacts; seat-priced lines consume the Service Account's roster. Projects connect delivery to the owning Service and relevant lines.
Exploratory Commercial Services	Migration source for existing reporting and reconciliation evidence; no new-deal writes or permanent parallel maintenance.

Rename both module API names and business-facing labels, as requested on 1 October 2026. Track affected integration changes in this repository and deploy them together with the CRM renames. The old names below identify the installed baseline, not permanent target API names. Verify target-name availability and the supported rename mechanism; preserve existing module, field and record IDs. Map customer, agreement, lifecycle, reporting and invoice relationships onto Services before implementing the accepted-service handoff. These mappings do not block the offer widget. A module API rename does not retarget a lookup pointing to the distinct exploratory Commercial_Services module.

Every new commitment uses the universal parent from the first iteration. A project Service is a legitimate record in the generalised module. Existing MSP records stay in place; non-MSP exploratory commitments need a reviewed mapping to an existing or newly created Service. Historical consolidation can follow the pilot, but the destination and generator-ownership rules are Phase 1 decisions.

Foundation to reuse

Area	Repository baseline	Remaining work for the presentation
Commercial records	Operational `Managed_Services_Plans`, shared `MSP_Invoice_Lines` and exploratory `Commercial_Services`	Generalise and rename Plans and Lines as Services and Service Lines; use one parent for every new commitment and map exploratory evidence into it
Invoice evidence	Native Invoice and item attribution, service coverage and Xero identities	Link generated items to Billing Events and retain posted account/tax snapshots
Billing	Existing MSP generator selects Plan-owned charges using billing dates, not `Plan_Type` or `Plan_Status`	Explicitly route charges between legacy generation and Billing Events before new Services can enter generation
Accounting mapping	Product account defaults and line overrides exist in MSP preview	Validate and snapshot account/tax values per generated line
Reporting	Exploratory Commercial Services reporting, configured forecasts and explicit labour budgets exist	Redirect readers to universal Service identities during consolidation, then complete line allocation and performance work without counting both parents
Qwilr	The offer editor generates and updates Qwilr pages and retrieves selections; acceptance verification remains to be completed	Reuse generation in the widget, then verify accepted selections and revision identities before the Service Line handoff
Setup	`/offers?deal_id=<CRM ID>` provides the offer editor; `/service-planning` is a read-only preview	Reproduce the offer editor in a Deal widget first; extend to accepted-line review, Billing Event preview and activation after acceptance verification

The complete mixed hardware, setup and support workflow is a pilot target. Existing records or reporting screens alone do not establish that it operates end to end. Check live field metadata and active automations before preparing schema changes or a billing migration.

Rules throughout the flow

Reuse Managed_Services_Plans and MSP_Invoice_Lines record identities. Map exploratory Commercial_Services IDs explicitly to their destination Services. A renewal can update a commitment without creating another Service.
Give each charge one billing authority. Both generator entry points must enforce the same ownership decision; module labels, service types and lifecycle values are not sufficient protection against duplicate or unintended generation.
Product defaults assist entry. Saved line values describe the accepted terms; later catalogue changes must not overwrite them or issued invoice snapshots.
Keep selling quantity and price basis separate from labour hours. One setup fee can fund three hours; an instalment does not create another hours budget.
Keep invoice timing, charge applicability and delivery coverage distinct. Recurring billing can renew charges; finite instalments must end. Neither setting alone defines contractual renewal or unused-hour rollover.
Allocate invoice amounts, work and costs once. Preserve unresolved ownership and missing costs as visible gaps rather than assigning them arbitrarily.
Separate configured expectations, billed amounts, payments and any management allocation across coverage periods. Report periods and estimate bases must be explicit. Do not infer recognised revenue from a billing schedule.
Saving a draft does not activate billing. Acceptance, service activation, invoice drafting and invoice issue remain distinct events.

First working slice: bring the offer editor into CRM

The Deal offer editor provides the existing interface and Qwilr generation flow at /offers?deal_id=<CRM ID>. It saves and reopens drafts, creates or updates the same Qwilr page, and retrieves customer selections. The Deal's Business Category selects MSP or Tech Projects through ordered saved-block snapshots with dynamic Products. Staff edit surrounding narrative in Qwilr.

The next deliverable reproduces that interface in a widget opened from the Deal. All staff using CRM can prepare offers; this iteration adds no separate roles, per-user access rules or Pepperback login. Staff interact with the frontend; Pepperback retains validation, storage, CRM access and Qwilr operations behind an authenticated integration connection. Backend credentials stay out of the widget and its URLs.

After the widget works, test Qwilr acceptance through the existing manual refresh flow. Prove what acceptance returns before designing its Service Line and billing handoff. Automatic webhook notifications are a later convenience, not a prerequisite for the widget or the acceptance test.

Phase 1: guided Qwilr quote to invoice for new deals

Deliver the following steps in order. Start with the existing offer workflow in CRM, verify acceptance, then complete the commercial foundations and build the Service Line, Billing Event and invoice-draft handoff. Backend validation remains shared by every entry point. Historical cleanup does not gate this flow.

The shared editor package, offer-only backend authentication and persistent Docker storage are implemented with offline regression coverage. The backend was deployed from main on 27 October 2026, with the existing offer draft preserved and verified in the persistent volume. The shared connection and Deal button are installed for Administrator and Standard profiles on the Standard layout. The live administrator smoke test passed for loading 827 catalogue Products, save/reopen, the quote action retaining the existing page, and selection refresh. The original offer content and version remained unchanged. Finish the separate Standard-user and controlled generation/failure checks below. See widget setup.

[x] Package the existing offer editor with CRM Deal context, Product selection, MSP options, quantities, prices and billing frequencies.
[x] Install Prepare offer as a Deal button invoking the widget for all staff.
[x] Keep access simple: all CRM staff can prepare offers, with no additional role model, per-user access rules or separate Pepperback login.
[x] Configure one centrally managed CRM connection for authenticated calls to Pepperback through the widget SDK's connection invocation. Keep backend endpoints protected and all integration credentials out of frontend code and URLs. Keep validation, persistence and Qwilr operations on Pepperback.
[x] Reuse and test save, reopen, generate/update the same Qwilr page and Refresh from Qwilr using the existing backend behaviour. Preserve offer versions, stable line identities and uncertain-write protection so retries cannot silently create another proposal or overwrite accepted terms.
[x] Retain the existing draft storage and add a shared persistent Docker volume.
[x] Preserve existing drafts in that volume before deploying the widget backend.
[x] Smoke-test the installed widget from CRM: load, save/reopen, retain the existing Qwilr page and refresh selections; reject unauthenticated backend calls.
[ ] Verify with a Standard staff account, including controlled creation/changed quote updates, revoked connection access and interrupted Qwilr requests.

Installing CRM Proposal Line records, configuring delivery budgets and previewing Billing Events are later handoff work, not prerequisites for reproducing the editor.

Done when: a staff member can open a Deal, prepare and reopen its offer, and create or update its Qwilr page from CRM without an additional Pepperback login. The backend remains authenticated and credentials are not exposed in the widget.

1a. Deal categories and released designs

Backend, widget and CRM configuration were released on 28 October. Evidence and remaining business validation are in the coordinated release.

[x] Keep one Deal picklist (Business_Category API name), with six canonical categories: MSP - New Client, MSP - Additional Product / Service, Tech Project, Tech Retainer, Hardware and Home. Preserve explicit legacy aliases for reads.
[x] Map categories to released saved-block compositions; only new-client MSP seeds plans and onboarding. Other categories begin without sold Products.
[x] Prepare Retainer-specific cover/scope/terms and shared plain pricing and acceptance blocks for MSP additions and Home. Hardware uses the plain design initially because the old master depends on a different integration.
[x] Keep all sold items and pricing in the offer, replacing template quote sections completely. Require review on category changes without discarding lines.
[x] Align project routing: new-client MSP, Tech Project and Retainer get Scoping; MSP additions, Hardware and Home do not. Retainer does not use one-time Reserved setup. Accepted-service linking and recurring delivery setup remain later work.
[x] Deploy backend/widget together; apply the Deal Category display label, required blank-default picklist and compatible CRM workflow criteria.
[ ] Verify each composed design and category with controlled records. Include category changes, legacy drafts and an account-less Home offer. Six live category/default and draft-save checks passed; one reusable Qwilr draft supports rendering and update checks. Preview acceptance and a separate Standard-profile session remain business validation.

Team members maintain master designs in Qwilr. Browser-assisted release runs save versioned block copies, validate their order/types and activate the reviewed registry. The release runbook records source masters, block identities and checks. Automated scheduling or a standalone AI harness is not installed by the category implementation.

2. Verify Qwilr acceptance before the service and billing handoff

[ ] Cover the five Qwilr journeys with an independent reusable test Deal and page for each: new-client MSP, MSP additions, Tech Project, Retainer and Hardware. Home is tested separately without a Qwilr acceptance journey. Reuse one Qwilr draft per scenario and repeat preview acceptance; capture sanitised fixtures for offline replay. Start with Tech Project and new-client MSP, then Retainer, MSP additions and Hardware. Fetch the result through Refresh from Qwilr; keep preview acceptance distinguishable from actual acceptance.
[ ] Verify the accepted plan, optional items, changed quantities, prices, totals and acceptance status. Check discounts and taxes where present and make unsupported or incomplete results visible for review.
[ ] Prove the link to the original Deal, Product, offer-line identities and generated revision. Preserve the signed proposal and accepted values; test commercial edits and unmatched additions made in Qwilr rather than assuming that the saved draft still describes the accepted terms.
[ ] Repeat retrieval to verify a stable result without creating Services, Service Lines, Billing Events or invoices. Record the verified mapping and unresolved cases before implementing the handoff.
[ ] Confirm the template and automated-page constraints relevant to the tested flow. The dated Qwilr research is background evidence, not the acceptance contract.

Manual refresh is sufficient for this checkpoint. Add automatic acceptance notifications only after the returned data and mapping are proven; webhook configuration does not gate this test.

Done when: acceptance across the five Qwilr categories and their supported offer designs can be retrieved and reconciled to the selected commercial terms and source revision. Ambiguous or unsupported cases have an explicit review outcome. This checkpoint must pass before implementing the accepted Service Line and billing handoff.

3. Complete the commercial foundations for the handoff

The checked items record the installed foundation. Complete the remaining service and billing preparation after acceptance verification and before enabling the handoff; it does not block the offer widget.

[x] Inspect Plan/Line fields, lookups, required values, buttons, workflows and middleware dependencies. Prepare the Services / Service Lines display and API renames while preserving module and record IDs. The prepared mapping records live metadata, reusable fields, additions and dependencies. Five installed standalone bodies were verified as middleware wrappers during implementation.
[x] Rename the retained modules and deploy their tracked consumers: Client Services / Client_Services and Service Lines / Service_Lines. Verify module/record identities, lookup targets and live reads. Zoho reserves Service/Services; the standard Services__s keeps its original name. The cutover record records installed fields, safe defaults, reviewed controls and recovery evidence.
[x] Move MSP Seats to Accounts while preserving invoice quantities, dates, rates, annual renewals and prorate rules. Update billing, contact lifecycle, imports and reports; keep the legacy Service lookup as migration evidence. The Account seat migration records verification and deployment boundaries.
[ ] Complete the external-consumer audit for Flow, marketplace configuration and deployed BI before enabling the new-project pilot. Five installed CRM wrappers and the middleware are verified; this is not an exhaustive audit.
[ ] Generalise customer, Deal/agreement, lifecycle and delivery configuration. Reuse Plan as each new line's Service parent; remove MSP-only assumptions from new-deal validation without changing existing MSP billing semantics. The Standard layout labels, Draft/Cancelled choices and optional MSP-only fields are installed; new-flow activation validation remains to be implemented.
[ ] Specify and enforce explicit billing authority for each charge in both legacy and event-based generation before new Service records can be processed. The legacy generator now requires Legacy MSP; new lines default to Hold. The reviewed 167 parent-linked lines retain legacy ownership, while 26 unparented lines are held. Event-based generation remains future work. Plan_Type, Plan_Status and a display rename are not routing gates.
[ ] Define the exploratory-to-universal Service crosswalk and invoice/item lookup changes. New widget and integration writes use only the universal structure; historical migration is not a prerequisite for that path.
[ ] Start with one new project: Proposal Line, Qwilr quote, acceptance, Service Line, Billing Event and invoice draft. Extend to mixed hardware/setup/support and finite instalments through the same widget.
[x] Prepare the model's field-gap map against installed CRM metadata. Reuse compatible fields and relationships; the Services and Service Lines map identifies additions, existing invoice relationships, required-layout changes and the integer selling-quantity limit. Candidate API names and policies remain subject to configuration review and creation readback.
[ ] Define price basis, billing mode/frequency, first charge, applicability dates and milestone instructions independently of delivery coverage, budget type, hours, allowance period, rollover and completion.
[ ] Define Product defaults and permitted line overrides, including account and tax policy. Save effective accepted values and revision identity.
[ ] Specify Proposal Lines on the Deal and their mapping to accepted Service Lines. Specify Billing Event identity, source line, coverage, amount, release condition, state and invoice-item link.

Done when: the first case has reviewed mappings into the final Service and Service Line modules, explicit billing routing and a verified Qwilr acceptance contract ready for the handoff implementation. A new project cannot enter legacy recurring generation; an existing MSP charge retains its chosen generator. Unsupported quote behaviour is explicit.

4. Guide accepted Service Lines and Billing Events

[ ] Extend the widget with Proposal Line persistence and the verified acceptance mapping. Support reopening from the Deal or linked Service for setup and billing actions. Provide independent delivery budgets and preview billing dates or milestones, amounts and delivery coverage using backend validation.
[ ] Import selected items and accepted quantities/values only. Preserve the signed proposal and accepted revision, verify totals against the source and send ambiguous mappings or incomplete acceptance to review in the widget.
[ ] Prefill the service and lines from accepted terms. Explicitly choose create or update; confirm dates, delivery scope, budgets and account/tax exceptions. Integrate the accepted/Reserved handoff with existing Deal and Project automations without creating duplicate services or projects.
[ ] Show one-off, recurring and finite instalment schedules beside the independent delivery allowance or total budget. Guide milestone setup and release, with visible unreleased charges and an explicit end to finite schedules.
[ ] Support Save draft and Activate as distinct actions. Block activation on unresolved required values or concurrent edits. Generate Billing Events only from activated, reviewed configuration.
[ ] Use stable event identities from the source line and occurrence, with revision handling that cannot charge an already billed occurrence again. Make replayed acceptance, activation and milestone release safe to retry.
[ ] Handle unbilled schedule changes, cancellation and renewal explicitly. Preserve issued history; unsupported combinations remain review cases.

Done when: selected accepted terms populate the right lines once, the widget explains the proposed charges, and activation creates the reviewed schedule. Three instalments sum to the fee without repeating the delivery budget.

5. Create traceable invoice drafts from the guided flow

[ ] Reuse existing CRM/Xero clients and draft/issued-document protections. Define invoice grouping by customer, currency and relevant billing instructions.
[ ] Resolve each line's account from its approved override or Product default; resolve tax from the agreed policy. Hold export when required mapping is absent or invalid. Preserve account, tax, quantity, price, coverage and source identity.
[ ] Link newly generated native items to their universal Service, Service Line and Billing Event; retain returned Xero invoice/line IDs and creation status. Verify the draft against the accepted terms and due events in the widget.
[ ] Cover concurrent requests, interrupted writes, draft refresh and replaced CRM item IDs. Check an uncertain creation result before retrying; never treat a recreated subform row as a new charge. Show blocked/review states to operators.
[ ] Guide due-charge review and milestone release through the widget after setup. Keep invoice issue and sending under the agreed operator process.
[ ] Define safe credit, void and cancellation handling for the pilot: unsupported cases pause for review and must not trigger automatic rebilling. Full ongoing payment, credit and source-status reconciliation belongs to the later phase.

Done when: the operator can follow a new quote through acceptance to its invoice draft, each amount traces to one due event, reruns create no duplicates, and issued values survive later setup changes.

6. Iterate with new deals and projects

[ ] Prove the first project flow, then both worked examples below using new-deal fixtures and reviewed new pilot deals. Exercise preview before enabling writes.
[ ] Test optional Qwilr items, changed accepted quantities and proposal revisions through the widget, including missing values and interrupted handoffs.
[ ] Record which generator owns each pilot charge. Prevent the legacy generator and Billing Event generator from billing the same scope; existing MSP billing remains operational for records outside the pilot.
[ ] Preserve delivery settings and source links for later performance work. The exploratory reporting baseline remains available for unmigrated records; new Services need no duplicate exploratory parent. Complete historical allocation and expanded performance reporting are not initial exit criteria.
[ ] Define recovery: pause new generation, verify events and drafts, then resume only the chosen billing authority. Do not erase issued history.
[ ] Update implemented process pages, business rules and operator instructions when the corresponding workflow is delivered and verified.

Phase 1 exit: operators use the CRM widget to prepare a new Deal, generate its Qwilr quote, review accepted Service Lines and Billing Events, and create the correct invoice draft using the generalised Plan and Line modules, without a parallel Commercial Services record. Both worked examples pass; proposal revisions and replayed events do not create duplicates, and review cases are actionable. Historical customer reconciliation is not a prerequisite.

Later phase: reconciliation and performance completion

Build on the identities and accepted snapshots captured by the new-deal flow. Scope and schedule this work after the initial quote-to-invoice pilot is proven. Consolidation into the universal parent is part of this plan; the exploratory module is retained only until migration and reader/writer cutover are verified.

[ ] Inventory useful exploratory records, relationships and reconciliation evidence. Map each reviewed Commercial_Services record to a destination Managed_Services_Plans record: reuse the existing Plan for MSP commitments; match or create a Service for non-MSP commitments without duplicating one.
[ ] Transfer accepted terms, budgets, delivery scope, invoice ownership and configured-line matches where verified. Preserve source IDs, original dates, issued values and an auditable old-to-new crosswalk; keep unresolved evidence available for review rather than silently discarding it.
[ ] Repoint affected line parents, invoice/item attribution, Deal/Project links, reporting readers and integration writers through reviewed migration steps. Preserve stable line IDs and ensure each source amount is counted once across the transition. Validate totals and ownership before switching readers.
[ ] Retire the exploratory module and obsolete lookups only after all needed evidence is retained and dependencies are removed. Keep a recoverable snapshot and crosswalk; do not run permanent duplicate Service maintenance.
[ ] Define ongoing reconciliation of totals, payments, credits and source status, including its trigger, freshness checks and visible exceptions. The completed historical backfill alone does not provide this workflow.
[ ] Match existing invoices and items to accepted commitments using reviewed evidence. Preserve dates, IDs, seat Account ownership, legacy relationship evidence and issued values; do not infer ownership from current configuration.
[ ] Review migration candidates and unresolved historical cases in the register below. Define billing cutover and recovery per migrated charge; verify existing MSP seat eligibility, prorating and annual-seat behaviour before any cutover.
[ ] Calculate converted lines from their own price basis, coverage and allowance period. Remove the service-level Arrangement dependency for those lines while retaining an explicit compatibility path for unmigrated records.
[ ] Map Projects/time logs and purchase evidence to the relevant line. Provide explicit allocation for shared work, including setup alongside support.
[ ] Record completion and effective dates for fixed budgets; define how revisions, cancellation and reopening affect remaining delivery.
[ ] Show agreed values, billing evidence, recorded work/cost, remaining delivery and budget variance using consistent service and monthly totals. Label estimates and incomplete history; keep missing allocations visible.
[ ] Provide a verified path from a universal Service to its native billed items and parent Invoices. Recheck CRM related-list support; if necessary use a scoped query/report without recreating the retired capture modules.
[ ] Keep the AUD 1,000/month support management allocation separate from the AUD 12,000 July invoice. Implement that allocation only after its reporting definition is agreed.

Done when: Services is the single operational and reporting parent, the exploratory module is retired, reconciliation has a defined trigger and review process, migrated history remains traceable, and service/month totals count allocated work and financial evidence once. Partial history must remain visibly incomplete.

Pilot scenarios and acceptance checks

All amounts below are illustrative AUD values excluding GST. Use these as test fixtures; they do not instruct changes to an existing customer's agreement. Phase 1 proves quote generation, accepted configuration and invoice drafting. Recorded-work allocation and performance comparisons in these examples are checks for the later phase.

Scenario	Required result
CRM offer widget	Staff can open, save and reopen a Deal offer, generate/update Qwilr and refresh selections without a separate Pepperback login or additional role model. Backend requests remain authenticated and credentials stay outside the widget.
Acceptance checkpoint	After the widget works, manually retrieve acceptance across the five Qwilr journeys (Home is separate) and verify selections, quantities, values, status and source revision before implementing the Service Line and billing handoff. Webhooks are not required.
Universal structure and billing routing	New MSP, project and mixed commitments use Services and Service Lines without a duplicate Commercial Services parent. New event-owned charges cannot enter legacy generation; existing legacy-owned charges remain unchanged.
New Deal to invoice	Enter Proposal Lines in the CRM widget, generate Qwilr, import selected accepted terms, review Service Lines and Billing Events, then create the matching invoice draft. No historical import is required.
Quote selections and revisions	Optional items, changed quantities and revisions produce only the accepted lines. Preserve signed terms and source identities; ambiguous changes require review.
One laptop, setup and annual support in one service	Hardware has its own charge and purchase-cost basis. Setup is one AUD 599 fee with three total hours. Support has separate annual billing and monthly delivery rules. Later performance work allocates recorded effort to setup/support once.
Annual support	One AUD 12,000 charge for 1 July 2026 to 30 June 2027; eight hours per month. The later performance check shows a two-hour overrun for July's ten recorded hours, independent of the upfront invoice. At the illustrative AUD 50/hour, the cost variance is AUD 100.
Fixed project with instalments	Three AUD 4,000 charges at acceptance, work start and completion; one 80-hour budget. Unreleased milestones stay unbilled. No fourth charge and no repeated 80-hour budget.
Replay and change	Repeated acceptance, activation, milestone release and scheduled processing create no duplicates. A changed draft cannot rewrite issued items or release charges twice.
Later consolidation	Reviewed exploratory records map to one destination Service each. Retained invoice/line evidence and financial totals survive the switch; unresolved ownership remains visible.
Later reporting consistency	Service and month views use the same allocated totals. Discounts retain their sign; cumulative amounts use an explicit period. Partial months and incomplete scope history remain visible.
Incomplete data and failure	Missing mappings or required budgets, ambiguous allocation, concurrent edits and interrupted writes produce actionable review states; no invented zero costs or blind invoice retries.

Historical follow-ups and migration boundaries

The archived migration, cleanup and inventory record dated outcomes, not current production checks. Recheck each item before implementation; an old unresolved note is not proof that it is still unresolved. This register preserves unfinished work for the later phase. New-deal pilots do not depend on resolving unrelated historical customer records.

Historical item	Disposition in this plan
Attribution on new invoices and ongoing Xero reconciliation	Phase 1 step 5 retains source links and creation results for new invoices. The later phase defines ongoing reconciliation and exception handling; the September migration covered six invoices only.
Service navigation to native Invoiced Items	Define universal-parent relationships in Phase 1; migrate exploratory lookups and verify the service-to-item-to-invoice reporting path in the later phase. The September lookup targeted the exploratory module.
Tech Project labour, cost and recurrence extensions	Phase 1 defines and captures line-owned budgets and schedules. Full allocation, completion and reporting extensions follow in the later phase; verify the existing implementation before adding fields.
Gidget, Cercle and ARACY candidates	Later migration candidates, not initial new-deal pilot prerequisites or an approved all-customer import. Gidget's June invoice needs verified Deal/service ownership and a fresh check for a native CRM mirror; use prepared labour evidence only when reviewed. Preserve June dates and obtain suitable history rather than shifting activity into July. Recheck existing Cercle/ARACY lines and budgets before adding anything.
Success Works transition coverage and work ownership; Sharps commencement versus billing start	Resolve the accepted boundary if the affected scope enters a later migration pilot. Preserve historical Product/quantity exceptions and the zero-value CRM-only row; current configuration is not proof of historical terms.
Unassigned invoice ownership and INV-0299 customer mismatch	Later evidence review, required before migrating the affected scope. Do not infer ownership from a current Plan or backfill all unassigned headers. Mixed-service invoices retain item-level attribution.
INV-22223031 source-status drift	Recheck the archived AUTHORISED-to-VOIDED discrepancy against current evidence before including it. Preserve the source-drift guard; do not mark it resolved by moving this document.
Native credits and multi-month allocation	Phase 1 step 5 requires safe review handling for credit/void cases. The later phase completes reconciliation and defines any management allocation. Historical credit-adapter limits and unresolved multi-month allocations remain explicit until verified.
Parent-module consolidation	Generalise Plans as Services in Phase 1, preserving IDs. Consolidate and retire exploratory Commercial Services in the later phase, preserving useful reconciliation evidence. Plans are the retained foundation.
Broad history imports, scheduled/incremental report refresh and Delivery Model retirement	Require separate scope within or beyond the later phase. Pilot history must still be sufficient for the claims made; no lifetime results from partial history.

Business choices to settle during Phase 1

Felix and Lou can settle these through the worked examples, with the person responsible for invoicing confirming accounting and issue rules:

What operator checks are required for activation, milestone release, account exceptions and invoice issue in the later billing pilot? These checks do not introduce an access-design prerequisite for the offer widget; all CRM staff can prepare offers.
What are the rules for partial periods, rounding, allowances, rollover, renewals, early cancellation and unbilled instalments?
Which Qwilr edits, selections and revisions can be mapped reliably, and how does the widget route unsupported cases to review?
Which new deals and projects enter the pilot, which generator owns each charge, and what evidence is required to expand the rollout?

Settle shared-work allocation, cost-estimate presentation and any monthly management allocation during the later performance work. Those decisions must remain separate from billed revenue and cash.

Dates and effort estimates remain unset. The next implementation step is the CRM offer widget using the existing editor and protected Pepperback backend. Acceptance verification follows, then the reviewed Service Line, Billing Event and invoice-draft handoff using the installed structure, legacy ownership and MSP entitlement guards. Expand the completed flow through the worked examples before taking on historical reconciliation.

Implementation references

Work area	Starting points and existing tests
Offer widget and acceptance	`app/blueprints/offers.py`, `templates/offers.html`, `templates/offers.js`; `tests/test_offers.py`, `tests/js/offers.cjs`; Deal offer editor
Shared records and attribution	`commercial_services/`, especially native invoice history and charge links; `tests/commercial_services/`
Billing and accounting	`msp_imports/msp_invoices/`; `tests/test_msp_invoice_preview.py`, `test_msp_invoice_service.py`, `test_msp_invoice_payloads.py`, `test_msp_invoice_refresh.py`
Schedule preview and setup	`app/service_planning/`, `app/blueprints/service_planning.py`; `tests/service_planning/`
Forecast and performance	`app/commercial_margin/financial_forecast.py`; `tests/test_financial_forecast.py`, `test_mixed_service_lines.py`, `test_service_monthly_activity.py`

Extend offline regression coverage for the pilot outcomes and existing MSP behaviour as each step is implemented. Exact APIs and CRM field names must be validated against current official references, metadata or existing code before implementation. The MSP invoicing process, Deal process and invoice integration reference remain the references for running workflows.

Consulting pricing configuration — 28 October 2026

Consulting pricing uses two CRM Products (Consulting and Senior Consultant), with standard hourly/daily rates and a nonprofit discount percentage on each Product. Unit and Standard/Nonprofit selection belong to the offer line. Rates are snapshotted and explicitly refreshed; nonprofit pricing remains a visible named discount. The offer editor also supports named manual line discounts and separate section adjustments through Qwilr's native discounts. This does not implement invoice allocation or Service activation. See the owning offer rule and staff procedure.