Cloudworkz Group — Financial & Organizational Strategy Plan

Living working document · Compiled 2026-07-12, merged with the live Xero pulse 2026-07-13, correction pass applied 2026-07-13, second correction pass applied 2026-07-13 (project-admin section, Roy, finance-access restored), third pass same day (prospective-client mentions removed, not proceeding) · Owner: Tom King · Entities in scope: Cloudworkz, Unlock, XLR8 (The Real Accelerator), Yachay, Kurai
Status: living document, now a single merged file This replaces the two separate files from 2026-07-12 (the static strategy plan and the standalone "group-xero-pulse" artifact) with one document: the full strategy narrative plus the live-refreshing Xero pulse embedded directly in Section 6. The live refresh only functions when this page is opened as a Cowork artifact (it calls window.cowork.callMcpTool); opened as a plain downloaded file, the widget still displays the last-known figures saved in it, with a note that live refresh is unavailable in that view. Everything below reflects understanding as of today, built from the transcript-based strategy brief, the live (but flagged-unreliable) Xero connection, bank statements already in the vault, and this project's own working notes. A full line-by-line correction pass was applied 2026-07-13 following Tom's review, and a second pass the same day restored several items found missing when Tom compared this document against his original pasted brief — corrections are marked inline.

1. Executive summary

How money enters the business, and why a pound isn't a pound: there are four kinds of cash/revenue, and they aren't equal in value to the business — nor equally reliable.

Tier 1

Investment

Highest value per pound

No costs attached beyond what's already tied to that operation. A pound of investment can be deployed wherever decided. ~£158,000 received to date for Unlock — all from investors (shareholders, not clients/customers); Unlock isn't trading.

● Currently resourced — Unlock fundraising is a protected priority

Tier 2

Art sales

Fixed margin

Peruvian art, via Yachay/Kurai. Simple transaction, but a real cost of goods — margin known in advance (e.g. £10k generated, £5k fixed cost → £5k known margin).

● Currently resourced — the art business is a protected priority

Tier 3

Commercial / client services

Lowest value per pound, but fixed once running

No fixed margin defined yet, delivery risk, client management overhead, and the risk of costs outliving the service if it stops suddenly. Its offsetting strength: once an engagement is actually running, it behaves like fixed, dependable income — that predictability is where its value comes from, even though a pound of it is worth less than a pound of Tiers 1–2.

○ Paused — GG relationship on hold (see below)

Tier 4

R&D tax credits

Historically significant, currently unsized

Not new revenue — a credit reclaimed against R&D-qualifying costs already spent. Has previously been material: significant R&D payments were received in 2023 (exact figures to be reconciled directly from Cloudworkz's Xero, not stated as a fixed number here), and the most recent such payment was applied to reduce an outstanding bill rather than paid out in cash, not the outcome expected at the time (see the caution below and Section 8).

◐ Sizing in progress — see Section 8

Working framework: Tiers 1–3 are cash sources, ranked by quality — cost structure, margin certainty, and delivery/complexity risk — not just pound amount. Tier 4 sits apart, it's a reclaim against past spend, not new revenue. Tiers 1 and 2 are the two tiers currently being actively resourced — see the freeze below for why Tier 3 is not, and the caution below for why Tier 4 isn't being spent against yet either.

Value per pound vs. reliability of the pound arriving — two different axes. A pound from Tiers 1–2 is worth more once it lands (no attached delivery cost, known or no margin risk), but by nature that income is variable, not fixed: without the necessary time and effort (fundraising conversations, art deals actually closing), the amount realized in a given period can be zero. Tier 3, once an engagement is actually running, is the opposite: lower value per pound, but closer to fixed, dependable income while it lasts. Tier 4 is a different animal again: it isn't revenue at all, it's a credit against costs already incurred, and its value depends entirely on the reclaim being executed correctly — which the caution below shows can't be assumed.

Where things stand, and why only two tiers are active right now: the commercial-services relationship that generated most of this year's revenue (internally "GG" — Opulence Thoroughbreds / Opulence Bloodstock / GG Racing Limited) has temporarily paused while GG makes changes on their end. That pause, combined with the cash cushion from the first Peruvian art-sale closing, has been used as the deliberate trigger for a reset: rather than keep funding Tier 3 (services) at all, every cost not tied to Tier 1 (Unlock fundraising) or Tier 2 (the art business) has been stopped — including Unlock product development, since that's treated as a fundraising prerequisite (investors expect updates).

Concretely, this means the people and costs that were supporting GG specifically — and anything else not already tied to Tiers 1–2 — are paused, not the whole business. The freeze lifts once the organization has funds it can responsibly ring-fence for client acquisition/delivery (those funds could come from art sales or from fundraising — the principle is affordability and budgeting, not a specific named source), or a broader financial strategy, plan, and payment/tracking infrastructure are in place, whichever comes first.

New spending gate on Tier 4 (R&D), stated directly by Tom. The organization does not currently know what the potential R&D value is across the whole group. Establishing that — not just the illustrative sizing already done in Section 8, but genuine clarity on it — is a priority before making any further spending commitments tied to pursuing R&D claims (accountant time, admin, submissions). This is a direct lesson from the recent 2026 submission: money and effort were committed on the expectation of a cash payout, and the claim instead reduced a bill.

The big pivot this session: Tom has explicitly reframed priorities. With no real current profit in the businesses, R&D tax relief needs to be weighed against — not pursued ahead of — VAT reclaim on money already spent and a likely near-zero corporation tax position. R&D's value, if the entities are loss-making, is mostly a cash credit rather than a tax saving, which changes how urgent it is relative to VAT. In fact, the group is more likely to owe VAT than to have a reclaim due, which is exactly why it needs reconciling first. See Section 7 and Section 8.

Also new this session: Tom has stated directly that Xero cannot be trusted for reconciliation right now — see the truth hierarchy in Section 2. This is now the group's core working methodology for every financial workstream below.

2. Truth hierarchy (adopted methodological principle)

Stated directly by Tom, 2026-07-12: "we know that Xero is WRONG." Xero has invoices that will never be paid, credit balances that will never be collected, at least one voiding pass Tom ran himself without a matching reconciliation, and at least one likely misattributed payment (an Opulence payment possibly booked to the wrong entity). Xero is therefore excluded from the truth hierarchy until it has been reconciled against the three sources below — not used as a starting point.

RankSourceWhat it gives
1 — most reliableCash at handActual bank / Wise balances today, per entity.
2HMRC-submitted accountsThe last filed, audited position per entity.
3Bank statements since last submissionBridges the gap from the last filed accounts to today.
excludedXeroReconciled against the three tiers above, not used in place of them, until proven trustworthy.
Applies to every workstream below. The VAT and R&D sections both follow this: bank outflow first, invoice second, Xero last.
Zero-value discipline (Tom, 2026-07-12). A receivables, payables, or cash figure that reads exactly £0 (or effectively so) is not automatically a verified true zero — it may just mean the figure hasn't been reconciled, that entity's Xero isn't fully populated, or a genuine gap rather than a confirmed nil balance. Treat every zero the same way as any other Xero figure under this hierarchy: discount it until independently confirmed against a bank statement or the entity's own records, not accepted at face value because "zero" looks clean — unless independently confirmed directly by Tom, as with Unlock's figures (Section 6).

2a. How this project's own admin is managed

Restored 2026-07-13, per Tom. The original brief flagged, before Cowork built anything, that this work needed a settled answer on how it would be managed structurally — project, vault, indexing. That question applies just as much to the ongoing work now as it did at the start, so it's answered here rather than left as a historical footnote.

This is the practical answer to the original brief's §3.10 prerequisite — settled through use over the last two sessions rather than decided upfront in the abstract, which is a reasonable way for it to have resolved.

3. Entity & people register

Canonical spellings and current status, to prevent transcription drift. Several corrections landed this session.

Entities (five in scope)

EntityNotesStatus
Cloudworkz Limited (Co. 12801553)Operating company, spelled with a "z". Generating revenue again this year for the first time in two years (currently paused, see GG below).Active
Unlock Services LimitedFlagship product, EIS/SEIS investment platform. Tier 1 / top priority. Now VAT-registered. Not trading — all funds in are from investors/shareholders (~£158,000 to date), not client/customer revenue.Active — priority
XLR8 / "The Real Accelerator" / The Real EXLR8R Ltd (Co. 14586099)Lower priority than Cloudworkz: no investors, no litigation upside, doesn't own Lexi or SchoolVBE.Active — lower priority, long-term future undecided
KuraiArt-brand entity (Peruvian art). Holds £105k in Wise, confirmed as fact but not yet entered as a ledger line anywhere. Has not yet made any payments and is not yet connected to Xero. Companies/Kurai/ vault folder created 2026-07-13 (previously a structural gap).Active
YachayArt-brand entity. Exact split of the art business vs. Kurai still unresolved. Has not yet made any payments and is not yet connected to Xero.Active — role vs. Kurai open
Central ManagementThe originally proposed shared-cost vehicle (Co. 14093417) — confirmed this session as dissolved / never traded. Its underlying management-fee concept is still considered directionally correct and is being revisited via XLR8 as an interim Central Management vehicle. See Section 4 for the corrected history: the plan was aborted when Rob Summerhayes left, not tried and failed.Dissolved

People

NameRole
Tom KingFounder, CEO, sole director. Going forward: fundraising only.
ClaudiaDesign/brand, art sales, partner in the business. Bank account access.
Werner SnymanHead of Product. Fundraising + product development. Effectively irreplaceable — no Unlock fundraising or GG data delivery without him.
William CorkeHistorically accounting / Companies House / R&D submissions. Intended role going forward: growth / client-facing service delivery. Currently stood down from finance/ops pending the sequencing described in Section 4.
BlancaTitle confirmed 2026-07-13: Head of Finance (via email signature). Accounting-software access. Currently stood down alongside William, for the same sequencing reason.
NickJoining as Chief Strategy Officer — strategy and organizational operations, to take cognitive load off Tom.
JuanesWorked this year on Unlock Development alongside Werner. Substitutable, unlike Werner.
RoyRestored 2026-07-13, per Tom. Involved in data delivery alongside Werner (a real cost against the GG data service, Section 5), and separately supports Tom's fundraising activity.
The four people who've actually held finance/exec ground for the last three years, and who has what access. Restored 2026-07-13, per Tom (in the original brief, dropped from the 2026-07-13 merge). For the last three years the only people who've worked in finance or an executive capacity in the business are Tom, Claudia, William, and Blanca — Blanca worked in finance but wasn't part of the executive team. Access split: Xero / accounting software — Blanca and William. Bank accounts — Claudia and William. Payments (day-to-day, making them) — Blanca and William have been the ones managing this. Tom himself has never had bank access, never made a payment, and has never submitted anything to Companies House directly.
Why Cloudworkz carries more value than XLR8 — and what tempers that. Cloudworkz has shareholders/investors (XLR8 doesn't) and real litigation upside — potential value recovery from ongoing litigation matters with former directors (not named here — individual names aren't needed for this document; see the vault's Litigation folder, reviewed per-file, for detail). This adds to Cloudworkz's relative value over XLR8. That upside needs weighing against Cloudworkz's liability side, not treated one-sidedly: legacy debts and CCJs (County Court Judgments) owed to HMRC and to providers who have issued them, HMRC payment plans that exist but haven't been kept up with, outstanding VAT bills, and potential PAYE liabilities all sit on Cloudworkz's books. Share capital exceeding £1,000,000 is also on record, understood to route certain matters (e.g. winding-up/insolvency) to the High Court above a £150,000 threshold — mechanism not yet confirmed. A creditor issuing a statutory demand followed by a winding-up petition is judged unlikely (the amounts owed are less than it would cost creditors to pursue), but it's a live risk factor, not zero. Cloudworkz is confirmed VAT-registered (Section 6/7) — a real VAT-reclaim opportunity, but also a real ongoing VAT-liability exposure, both cutting against treating the shareholder/litigation upside as the whole picture.

4. Organizational strategy

Forward team structure

Tom: fundraising only. Claudia: branding + art sales. Nick: strategy/organizational operations (CSO). William: client-facing agency/data services (on hold, see condition below).

William & Blanca standing-down — the actual condition

Not simply "on hold until revenue," and not tied to one specific named source of funds either. The precise condition is having funds that can be responsibly ring-fenced for client acquisition/delivery, and a plan to do it — those funds could come from art sales or from fundraising; the underlying principle is affordability and budgeting, not which source they arrive from. This is sequencing, not a permanent stand-down — payments and HMRC submissions may well be handed back to William/Blanca once the financial operating system is built.

Updated 2026-07-13, per Tom: a second potential restart path (a prospective client, alongside GG) was briefly explored and is confirmed, same day, as not proceeding (the prospect doesn't have the funds). GG returning (Section 1) remains the one live restart path tracked here.

Central Management — current thinking

The legitimate underlying idea (one clean biller for shared costs, charging a management fee to the operating companies) is still considered correct — it was first proposed in 2023 and handed over as a proposed solution in 2024, not something that's been continuously in place since. Since the original Central Management entity is confirmed dissolved, the interim plan is to use XLR8 as the Central Management vehicle for now, set up with a Wise account, routing fixed-cost subscriptions/services through it. A separate, more specific intercompany VAT-timing idea (XLR8 invoices Cloudworkz, Cloudworkz reclaims VAT to pay down HMRC debt, XLR8 carries the resulting VAT bill) remains flagged for tax-adviser review — it is not the same as the standard management-fee model and should not be treated as agreed.

History: the 2023 Business Ecosystem plan — attempted before, aborted rather than failed

Located and read in full for this document: Copy of BusinessEcosystem_09Nov2023, a 10-slide internal presentation dated 9 November 2023 ("Synergy in Networks: A strategic alliance"), owned by Tom. It proposed exactly the Central Management + Agency model being revived above — this is not a new idea, it's a second attempt at one already proposed once before. Correction, 2026-07-13: it wasn't tried and found to fail. Implementation began but stalled when Rob Summerhayes left, and Central Management never actually traded (Section 3). Worth reading in full before repeating it unchanged, but the framing is "aborted before going live," not "tried and recurred."

The 2023 plan named three group entities at the time — Cloudworkz, Enterprise UK (EUK), and XLR8 — plus a proposed Agency and Central Management layer sitting above them. EUK and the standalone "A2Z Data" entity that appears in some of this project's older source material are not part of today's five-entity structure (Section 3); they're cited here purely for historical context, not as current entities to track alongside Cloudworkz/Unlock/XLR8/Yachay/Kurai.

The exact problems this model was meant to solve were already diagnosed once, in writing, in November 2023 — but the plan was aborted, not run to a failed conclusion. The 2023 deck's own "Addressing our Ecosystem Challenges" slide named three problems: (1) resource allocation inefficiencies — profitable business lines disproportionately subsidizing unprofitable ones, (2) financial mismanagement — funds used without considering the broader impact, cannibalizing capital, with the deck's own cited example being "Spotzer telesales taking resources away from both fundraising and VQL," and (3) strategic misalignment across entities, slowing decisions and diluting competitive edge. These are functionally the same class of problem this 2026-07 reset is responding to — the GG-relationship freeze, the cost-ownership cleanup in this section, and the whole truth-hierarchy exercise in Section 2 all exist because money and effort drifted across the group without a clean owner or a reconciled record. Since Central Management never actually traded, reviving it now isn't repeating a failure, it's finishing something that stalled — but what's actually different this time (ownership, sequencing, funding) is still worth naming explicitly rather than assumed.

The three models the 2023 deck itself weighed — this decision has already been made once

ModelMechanismMain risk flagged in 2023
1. Direct paymentEach business pays directly for the resources it uses; team members/resources invoice each business they serve individually.Underutilisation of shared resources if individual units are cost-averse; multiple invoicing channels create admin burden.
2. Centralised payment & reimbursementOne business acts as central payer for a shared resource, then allocates the cost back to the others based on usage.Complex to track and fairly allocate cost after the fact, possibly leading to disputes; the central payer bears the cash-flow burden upfront.
3. Central Management & Agency (chosen in 2023, being revived now via XLR8)A central entity manages shared resources, invoices the operating businesses for their usage, and pays the resources itself.Extra overhead/setup cost to establish; risk of centralised decisions not matching individual business needs; slower response times from the added bureaucratic layer.

Source: Copy of BusinessEcosystem_09Nov2023 (Google Slides, id 1yQcaQ4Zsu_e2W2zv_FIjcK77bRtz85nuelChODfJBCA), read in full 2026-07-13. A related, not-yet-incorporated document was surfaced in the same search — XLR8 Ecosystem Company Details (Google Sheet, dated 2024-05-15) — which quantifies a proposed intercompany fee model: 15% of funds raised by other group companies payable to XLR8, 35% of funds raised required to be spent with XLR8, and 30% of pre-tax profit payable to XLR8. That's flagged as an open item in Sections 12–13 for a future pass rather than folded into this narrative now, since it wasn't the specific document Tom pointed at — but it directly quantifies the "XLR8 fee" mechanism this section only describes qualitatively above, and should be reconciled against it.

Emergency cost freeze

Active rule: all costs paused except those tied to (a) the art business, or (b) Unlock fundraising/product development. Every remaining cost needs a named owner (person + entity/project); unowned line items flow to Tom for a keep/cut decision.

5. Financial strategy

Cash sources, ranked by quality

  1. Investment — highest value per pound, no attached costs beyond the raise. ~£158,000 received to date for Unlock, all investor/shareholder funds (Unlock isn't trading — these are not client/customer receipts). Variable, not fixed: requires fundraising time/effort, and can realize zero in a given period.
  2. Art sales — fixed margin, real cost of goods (e.g. £10k generated, £5k fixed cost → £5k known margin). Also variable in timing, subject to deals actually closing.
  3. Services — lowest value per pound: no fixed margin yet defined, delivery risk, client management overhead, risk of stranded costs. Its offsetting strength is that, once an engagement is actually running, it behaves like fixed, dependable income.
  4. R&D tax credits — not a revenue source at all, a reclaim against costs already spent. Historically material (see Section 8) but currently unsized group-wide; further spend committed to pursuing it is gated on establishing that size first, see Section 8.

Time-value / opportunity cost

Working hypothesis: it may be a false economy for Werner or Tom to spend time on client delivery if fundraising is the better use of that time. Tom's fundraising rate is currently only an estimated range, £2,000–£5,000/hour (~£85,000 raised since December) — not yet a real, calculated figure. Queued task, 2026-07-13: calculate the actual rate by pulling Tom's total Aircall call time (starting from his first-ever call with Tony Vine-Lott) plus Google Meet time spent with investors, summing total call/demo hours, then dividing the total amount raised by that total — replacing the estimated range with a real number (see Section 13).

Entity priority

Unlock is the Tier 1 priority: no VAT bills currently, no profit (pre-revenue/investment-funded), maps directly to the highest-value cash source (investment).

Client services true cost (unresolved)

Profitability of the GG relationship is unclear — unaccounted-for costs include Werner's time, Roy's time (data delivery, restored 2026-07-13), Tom's and Claudia's time, Roxi cost, Axiom (Lead Bucket Optimizer) build time, and Claude usage. A proper cost model with a defined margin is needed before restarting.

6. Xero data captured so far

Reminder: Xero is flagged not reliable for reconciliation (Section 2). The figures below are raw pulls, useful as a data point to cross-check against cash-at-hand and HMRC accounts — not treated as ground truth on their own.
Cash balance source, and what it isn't (Tom, 2026-07-12). The "cash balance" figures below come from Xero's bank-account-level report — its closest analog to the actual bank connection, not the balance-sheet total. That's a meaningfully better source than a derived accounting figure, but it is still Xero's own record of the bank feed, not the bank statement itself. It still needs independent verification against the real bank/Wise balance per the truth hierarchy (Section 2) — a Xero-reported bank balance is a data point, not confirmed cash at hand.
Zero-value figures need the same discounting as everything else — except where independently confirmed. Where receivables or payables read £0 (or effectively so) below, that is not automatically a confirmed nil balance — it may simply mean nothing has been reconciled against that line yet. Discount it until independently verified, per the zero-value discipline in Section 2. Exception, confirmed by Tom, 2026-07-13: Unlock's £0 payables and receivables are genuinely nil — Unlock has no debts and nothing owed to it, confirmed directly, not just an unreconciled Xero artifact.
EntityStatusWhere the data lives
Cloudworkz LtdPulledXero cash position £37,382.74 pulled. Correction, 2026-07-13: receivables, payables, and net-equity figures previously shown here have been removed — Cloudworkz's Xero invoice/debt data is unreliable and needs cleanup before being stated as numbers; better described as uncollected invoices and debts that are currently unreliable than repeated as specific wrong figures. Cloudworkz is confirmed VAT-registered (Tom, 2026-07-12) — the VAT-reclaim plan in Section 7 can proceed on that basis.
XLR8 (The Real EXLR8R Ltd)PulledFigures captured inline in this project's working notes (FY24/25, FY25/26 P&L both bases, receivables aging, cash-basis P&L) — not yet moved into its own standalone extract note for consistency with the Cloudworkz one.
UnlockPulledFull extract captured. Cash balance £5.72 — functionally out of cash. Correction, 2026-07-13: Unlock has no receivables — it is not trading, and the earlier framing of £39,001.50 in "receivables from Barwise/St Louis" was wrong; that money is investor/shareholder capital (~£158,000 raised to date), not client receivables. Net equity £132,993.71, but with unusual negative liability figures flagged for accountant review. Combined Sub-Contractor spend across both open periods is £31,165.29 — likely understated: Unlock has raised and spent roughly £158,000, so true costs should track closer to that figure, not just the Sub-Contractor line (see Section 8). Salaries/Directors' Remuneration/Employers NI/Pensions all show £0 in both periods — if Werner/Juanes/Tom's platform-development time is being paid via Cloudworkz or XLR8 and never recharged into Unlock's books, Unlock's true qualifying R&D spend could be materially higher than this figure shows. Also flagged: nearly all "income" is booked to "Other Receipts – Investment Funds," i.e. investor money recognised as P&L income rather than equity/liability — unusual treatment that applies to Cloudworkz's investment too, not just Unlock's (Section 9) — and it directly affects whether Unlock is actually profitable or loss-making (relevant to the VAT/R&D pivot in Section 7/8, and to the revenue-provenance plan in Section 9).
Yachay / KuraiNot yet connectedCorrection, 2026-07-13: Yachay and Kurai haven't made any payments yet and aren't yet connected to Xero — the earlier statement that "all five entities have their own Xero organisation" doesn't hold for these two. See the connector limitation below for why pulling either, once connected, needs a manual step from Tom.
Urgent, tier 1 of the truth hierarchy. Unlock's Xero cash balance is £5.72. Even allowing that Xero isn't fully trusted (Section 2), this is stark enough to prioritise directly against actual bank/Wise balances today, not left until the general "confirm cash at hand" task in Section 13 is reached in its normal order.
Confirmed tool limitation. The connected Xero MCP only exposes account-level tools (cash position, contacts/receivables, financial position, org info, P&L, top customers) — no transaction-level report (no bill list, no general-ledger export, no invoice list by account) is available, confirmed again today with a broadened tool search. Itemized transaction data has to come from a Xero-side Account Transactions export or from bank statements, not from this connection.
Single-organisation connector, confirmed still true today. This connection only ever authenticates one organisation at a time and has no list/switch-tenant tool — connecting a new entity replaces access to whichever one was connected before. Cloudworkz, XLR8, and Unlock are captured above; Yachay and Kurai still need to actually be connected to Xero (and have payment activity) before their figures can be pulled and added to the combined group financial extract spreadsheet (delivered alongside this document, see the note at the end of Section 6).

Combined figures for Cloudworkz, XLR8, and Unlock have been pulled together into 2026-07-12-group-financial-extract.xlsx, delivered alongside this document — a snapshot, not a live feed (see the callout above for why "live, all five entities" isn't achievable with this connector as configured today).

Weekly Xero Pulse — live, embedded below

The dashboard directly below is now embedded in this document rather than living in a separate file. It refreshes whichever entity's Xero is currently connected each time this page is opened as a live Cowork artifact, stamping that entity's card with today's date, while the other four keep showing their own last-known figures and dates — the practical answer to the single-organisation connector limitation above. Cloudworkz and Unlock are seeded with today's real figures; XLR8, Yachay, and Kurai show "not yet pulled" until the Xero connection is switched to each in turn at least once.

Recommended cadence: weekly, ahead of the weekly review. Switch the Xero connection to the next entity in rotation before each review and reopen this document — over a few cycles every entity stays current within roughly one week's staleness at any given time.

Live status — Cloudworkz Group Xero Pulse

Loading…
Live refresh is unavailable in this view (this page isn't running inside the Cowork artifact sandbox). Showing the last figures saved into this file. Open the live Cowork artifact version of this document to get a fresh pull.
EntityCash balanceReceivablesPayablesNet equityLast updated

This is a status/reconciliation tool, not the financial control system evaluated below — see the next subsection for the distinction.

Financial control system — evaluation against the reference wireframe

Flagged directly by Tom: the combined extract and the weekly pulse above are a current-status snapshot, not a proper financial control system. That's correct, and worth being precise about the difference rather than treating "we pulled Xero data" as equivalent to "we built the financial operating system" the roadmap (Section 10) actually calls for.

Reference evaluated: Combined weekly P&L_Wireframe V.1 (reference copy) (Google Sheet, already flagged in this project's document index as "a prior attempt at exactly the combined-P&L goal"). Its actual structure, read directly for this evaluation:

Cost-center structure needs updating for the current entity set. The reference wireframe's cost centers above (including "A2Z Data/VQL") were built against an older entity list — A2Z Data no longer exists in the group. Any cost-center structure adopted going forward should map to the current five: Cloudworkz, Unlock, XLR8 (interim Central Management/Agency vehicle, Section 4), and Yachay/Kurai for the art business (the split between the two still open, Section 3) — replacing the old A2Z Data/VQL line rather than carrying it forward unchanged. This mapping still needs agreeing with Tom and William; it's tracked as an open item in Section 13.
Group financial extract + weekly pulse (delivered)Reference wireframe (the actual bar)
GranularityPoint-in-time (as of connection date), fiscal-period P&LWeekly, rolling across the year
Cash detailXero's aggregated cash position per entityIndividual bank-account balances, named and numbered
Forward viewNone"To come this month" per account
StructureBy legal entity (matches Xero orgs)By cost-center/revenue-line, cutting across entities — needs remapping to drop A2Z Data and reflect Yachay/Kurai (see callout above)
ExpenditureXero's expense-account categories onlyFull weekly expenditure by cost-center, alongside revenue
Update mechanismManual Xero reconnect per entity, live artifact refreshDesigned for a standing weekly update habit (not currently kept up)
Honest verdict. What's been delivered is a genuinely useful reconciliation layer — it's the "cash at hand vs. Xero" check the truth hierarchy (Section 2) needs, and a reasonable stopgap "is anything on fire" pulse. It is not the financial control system itself. Building that means: (1) sourcing real bank-account balances and near-term cash movements — currently blocked, no banking connector exists (Section 7's per-entity bank-statement gap table is the same underlying gap), (2) agreeing the cost-center structure with Tom/William, including the A2Z Data → Yachay/Kurai remapping above, since it doesn't match the five Xero orgs one-to-one, (3) a weekly bank-outflow categorization process — an extension of the same bank-outflow-first method already adopted for VAT and R&D (Section 7/9), not a new one, built as automation not manual work, (4) the revenue-provenance discipline in Section 9, so inflows are trusted as much as outflows are, and (5) someone actually keeping it current every week, which is a process commitment, not a tooling gap.

Source: Combined weekly P&L_Wireframe V.1 (reference copy), Google Sheet id 1KYuFmRdXQ03GL9bE2OzZ-XCNWH06Ukeu1_e8ZFS9Xro, read directly for this evaluation, 2026-07-12.

7. VAT reclaim workstream

Why this now outranks R&D: no real current profit exists in the businesses, so corporation tax is likely near-zero — meaning R&D relief mostly produces a cash credit rather than a tax saving. Correction, 2026-07-13: the group is more likely to owe VAT than to have a reclaim due — that's exactly why VAT needs reconciling first, not because a refund is expected.

Method (Tom's explicit instruction)

Bank outflow first, invoice second — not the reverse, since invoices can't currently be trusted. Build note, 2026-07-13: this will be built as a Cowork/Code automation, not performed manually.

  1. Extract bank statements into a structured outflow list (date, payee, amount) per entity.
  2. Flag candidate VAT-bearing outflows (UK-vendor subscriptions, professional services, software) — excluding intercompany transfers and non-UK counterparties. Caution, added 2026-07-13 per Tom directly: do not exclude "personal-looking" payees by assumption — company payments have sometimes been made from personal accounts, so a personal-looking payee name is not on its own evidence a payment was non-business. Confirm purpose per payee, don't filter on appearance.
  3. Gmail-search each candidate (vendor, date, amount) to locate and confirm the actual invoice and VAT rate charged.
  4. Build the reclaim list from confirmed matches only.
  5. Separately confirm which revenue lines are genuinely output-VAT-free (non-UK licensees — Opulence, and similar), so the net VAT position isn't overstated.

Per-entity status

EntityBank statement sourceStatus
Cloudworkz19 monthly statements in Finance/ (Sep 2023–Mar 2025)Not actually extracted for Cloudworkz — those statements are Tom's personal account, not the company's. Real task: identify bank statements for every entity across all banks and centralize them in one folder, unless the data can instead be pulled directly from Xero.
XLR8Not yet locatedOpen gap
UnlockNot yet locatedOpen gap
YachayUnclear if any bank account existsOpen gap
Kurai£105k known Wise balance, no statement source locatedOpen gap

Tracked in Finance/VAT/CLAUDE.md. Not tax advice — VAT error-correction/reclaim time limits (HMRC's general four-year cap is the rule of thumb) need confirming with an accountant before anything is submitted.

8. R&D tax credit workstream

£915,850.47 – £941,164.34
Combined known qualifying spend across Cloudworkz, XLR8, and Unlock (cash-paid, Xero-verified), depending on whether Unlock's Period 1 is included and how narrowly Unlock's spend is scoped (Sub-Contractor line only vs. total expenses). Unlock's own figure is likely understated — see below.
£192,000 – £226,000
Illustrative maximum group R&D claim range, at the 21–24% ratio used throughout this project (the group's one real paid-out claim outcome). This is a sizing exercise, not a technical assessment — every number still needs a per-project qualifying review with an accountant before anything is filed.
Unlock's true qualifying spend is likely understated, not simply "smaller than assumed." Unlock's combined cash-paid Sub-Contractor spend across both open periods is £31,165.29 — at the 21–24% ratio this alone only sizes to roughly £6,550–£7,480, a small slice of the headline range above. Correction, 2026-07-13: Unlock's true costs must be higher than this — it has raised and spent roughly £158,000, so real spend should track closer to that figure, not just the Sub-Contractor line. Two further items flagged as necessary, separate work: (1) a clear, group-wide picture of all intercompany transfers, and (2) a description of the relationships between entities that aligns with what HMRC were actually told when accounts were submitted. Also worth checking whether Werner/Juanes/Tom's platform-development time is being paid via Cloudworkz or XLR8 and never recharged into Unlock's books (Section 6), which is part of why Unlock's true qualifying spend is understated here.

Historical significance, and the caution behind the new spending gate

R&D tax credits have historically been a significant source of cash for the group, at times described as having "saved" the business. Tom recalls significant R&D-related payments from 2023 — exact figures not stated here; worth checking directly against Cloudworkz's Xero rather than relied on from memory. The most recent such payment was applied to reduce an outstanding bill rather than paid out in cash, which was not the outcome expected or planned for at the time. This matches the pattern already on file for the Accelerate/XLR8 claim example: a payout withheld pending submitted accounts, then absorbed into a VAT bill once accounts were filed, rather than landing as cash.

Resolved, 2026-07-13: this is one event, not two. Per this project's own R&D claim history (Finance/R&D tracker): Cloudworkz's only claim on file is FY22/23 (period ended 31 August 2023), project "FutureSight AI"/"PulseIQ", £538,430 qualifying expenditure, £125,824 tax credit, claimed via SeedLegals — and the FY24/25 accounts note a matching £126,224 received from HMRC in November 2024, confirming it landed as cash. Tom's "significant numbers from 2023" recollection and the £126,224 November 2024 credit are the same claim: filed against the period ending 2023, paid out in cash in 2024.
Resolved, 2026-07-13, via Gmail: the "recent 2026 submission" is Cloudworkz's 2026 R&D claim, and Tom's own 2026-07-11 email to William confirms the lesson directly — the claim "was then withheld because we hadn't submitted accounts" for the relevant period, so the expected cash payout didn't materialize. In the same email Tom also flags a second, related suspected error: R&D-qualifying payments may have been made through XLR8 instead of Cloudworkz, which would misallocate spend away from the entity actually filing the claim. Both points strengthen the case for the intercompany-clarity work already flagged above and in Section 9 — payments need to sit against the right entity before any further R&D claim is filed.
Spending gate (Tom, 2026-07-12): the organization does not currently know its potential R&D value across the whole group, beyond the illustrative sizing above. Understanding that properly is a priority before committing further spend to pursuing R&D claims (accountant time, admin, submissions) — a direct lesson from the recent 2026 submission, where spend was committed on the expectation of a cash payout that didn't materialize as such.

Why this is now weighed against VAT, not pursued ahead of it

If the entities are loss-making, R&D relief functions mainly as a cash credit rather than a tax saving — see Section 7 for the reframed priority order.

Next step: itemizing the payments

The aggregate figures above are sized; the next task (not yet started) is turning them into an itemized payment list — date, payee, amount, account/category, matched invoice yes/no — per entity, so invoices can be found, created, or requested for each one. HMRC's own compliance letter to XLR8 already asks for exactly this level of detail (categorised costs with named staff/subcontractors, amounts, and support), so this is a real filing requirement, not optional groundwork.

Data exists, just not organized yet. The underlying transaction data isn't missing — no Xero tool in this session returns transaction-level detail directly (confirmed again today), but Xero Account Transactions exports are expected tomorrow for Cloudworkz (FY23/24, FY24/25), XLR8 (FY24/25, FY25/26), and Unlock (Period 2 — Period 1 looks unclaimable). Once organized, itemization and invoice-matching (Section 9) get built into a tool, not performed manually.

Per-entity claim windows and notification-form status tracked in Finance/R&D/CLAUDE.md. Not tax advice — every figure needs per-project qualifying review with an accountant before filing.

9. Invoice-matching & revenue provenance methodology

Correction, 2026-07-13: the underlying data already exists — from tomorrow's Xero exports, or bank statements where Xero doesn't cover it — it just needs organizing. Once organized, the sequence below gets built into a tool, not performed manually, for finding, creating, or requesting the invoice behind each payment line:

  1. Start from real transaction data — actual figures and dates, not estimates.
  2. Search all relevant company email (Gmail) for messages matching those figures/dates.
  3. Also search by named payee (subcontractor/vendor name) across email and Google Drive/files for anything matching, not just amount/date.
  4. Anything still not found after email + file search: fall back to a web search (company registry, invoice portal, public record) before treating it as genuinely missing.

Applies per payment line once the itemized list exists — not against the aggregate totals. This is the same evidence discipline already used for VAT (bank-outflow first, invoice second), applied to R&D, and built as automation rather than manual work (see Section 7's build note).

Revenue / fund provenance plan (inflows)

The bank-outflow-first discipline above traces spend to evidence. The same discipline needs to run in the other direction: every inflow landing in Xero or a bank account should be traceable to a known, verified source before it's treated as confirmed revenue — "where is this actually coming from" needs as firm an answer as "where did this actually go."

  1. Start from the actual bank/Xero inflow — date, amount, counterparty name exactly as it appears on the statement, and the receiving entity.
  2. Classify it into one of four categories before anything else: investment (Tier 1), art sale (Tier 2), trade/services revenue (Tier 3), or intercompany transfer — never left as generic, unclassified "income."
  3. Match that classification to an actual source document: an investment/subscription agreement, an art-sale invoice or receipt, a client invoice, or an intercompany loan/management-fee note. Use the same Gmail + Drive + named-payee search sequence as the invoice-matching method above, just run against the counterparty on the receiving side instead of the payee on the spending side.
  4. Anything that can't be matched to a source document gets flagged as unverified revenue, not accepted as confirmed income — the same treatment the zero-value discipline (Section 2) gives to unverified zero balances.
  5. Only counterparty-verified, source-matched inflows should feed the combined financial extract, the weekly pulse totals (Section 6), or any margin/profitability read (Section 5, Section 8).
Why this matters right now, not just in principle. Unlock's Xero books nearly all "income" to "Other Receipts – Investment Funds," investor money recognised as P&L income rather than equity/liability (Section 6). Correction, 2026-07-13: this applies to Cloudworkz too — both entities have had investment, and neither should have that investment recorded as income. Without a provenance step like this, that misclassification silently overstates revenue and blurs the line between Tier 1 (investment) and Tier 3 (services) cash described in Section 1 — two things this document is explicit are not the same kind of pound. The same risk applies to intercompany transfers between Cloudworkz, XLR8, and Unlock (e.g. the planned XLR8-invoices-Cloudworkz VAT-timing idea in Section 4) — a clear, group-wide picture of all intercompany payments is needed so each one can be either properly invoiced or properly organized, rather than risk being miscounted as external revenue if not tagged as intercompany at the point of classification.

This is new methodology, not yet applied to any entity's actual inflows — the next practical step is running it against Cloudworkz's and Unlock's already-pulled receivables/top-customers data (Section 6) as a first pass, once bank statements are available to cross-check against (Section 7).

10. Plan / roadmap

Named goals (not exhaustive)

  1. A clear, consolidated picture of organization-wide finances.
  2. A centralized-payment solution (Central Management system, via XLR8 interim).
  3. All companies consolidated onto a single Xero setup (still in tension with per-entity Xero/Wise accounts described elsewhere — flagged as an open question, not yet resolved).
  4. Blanca and William understanding and supporting the decisions being made.
  5. Live financial artifacts pulling in real-time information.
  6. Defined processes.
  7. R&D skills/tooling set up.
  8. Clarity on what needs to be measured.
  9. Guardrails in place.

Other in-flight ideas

11. Operating principles

12. Open questions

13. Outstanding tasks, priority order

Reordering principle, adopted 2026-07-13: tasks are prioritized by their potential to recover R&D funds. Anything already accessible and doable directly (vault edits, analysis of already-available data) is done rather than listed here — this list is for genuinely blocked items (pending connector authorization, Tom/William's input, or external parties) or larger deliverables not yet started.

  1. Corrected, 2026-07-13 The two most-recently submitted HMRC accounts sets (Cloudworkz FY24/25, XLR8/EXLR8R FY2025) were already extracted 2026-07-12 (Cloudworkz: net assets £156,881, cash £2,718, VAT liability £78,858, PAYE £43,998; XLR8: turnover £766,890, operating profit £187,037, net liabilities £(302,995)). The GROUP STRATEGY – INTERCOMPANY Drive folder and William's separate "Combined P&L_Wireframe" file were also already opened 2026-07-12 — this task's earlier "not yet done" framing was wrong. Genuinely remaining: two draft documents inside that folder, "Cloudworkz_RnD_Language_and_Consistency_Guide_V5_DRAFT" and "Cloudworkz_Group_InterCompany_Agreements_V4_DRAFT", located but not yet read in full.
  2. Resolved, 2026-07-13 Cloudworkz's £126,224 (Nov 2024) R&D credit is not a separate figure needing reconciliation — it's the confirmed payout of the FY22/23 FutureSight AI/PulseIQ claim (Section 8). Also resolved: which 2026 submission Tom's bill-reduction lesson refers to — confirmed via Tom's own 2026-07-11 email that the 2026 R&D claim was withheld pending unsubmitted accounts, with a suspected second error of R&D spend paid through XLR8 instead of Cloudworkz (Section 8).
  3. In progress Full review of all payments to Blanca and William, all accountant payments, and all outstanding accountant invoices (Section 12). First-pass Gmail findings, 2026-07-13: William is owed £12,592.04 as of his 2026-07-11 "Stepping down" email/timesheet, on top of already having been paid roughly half of an already-low agreed rate. Cloudworkz's accountant, More Than Accountants, has sent four unanswered reminders to William (27 Apr, 12 May, 1 Jun, 29 Jun 2026, all cc'd to Tom) requesting information needed to complete Cloudworkz's year-end accounts for the period ended August 2024 — a live filing-risk gap, not yet actioned. Roy (data/agent services) sends recurring monthly invoices to William/Blanca needing acknowledgement, under a payment process Claudia set out 2026-07-08 (cut date 1st, pay date 5th). Blanca's specific payment history not yet isolated. Full itemization still to come. Scope widened 2026-07-13, per Tom: this is now a full all-people payments audit, not just Blanca/William — see Projects/Financial-Organizational-Strategy/2026-07-13-all-people-payments-audit-scope-V1.md for the scoping pass and first findings (Cloudworkz personal-account outflow analysis, the newly found intercompany-accruals Drive archive). Also carries the "don't assume personal-looking = non-business" methodology correction (Section 11).
  4. Blocked — input gap Calculate Tom's actual fundraising £/hour: total Aircall time (from his first call with Tony Vine-Lott) plus Google Meet time with investors, divided into total amount raised (Section 5). Checked 2026-07-13: Team/_unmapped-aircall/ holds 72 transcripts, but only across five person-named folders (fin-opulence, georgia-opulence, josh-opulence, kate-opulence, sophia-unlockdd) — none reference Tony Vine-Lott or read as Tom's own investor calls, and no live Aircall or Google Calendar/Meet connector is available this session. Needs either a live Aircall/Calendar connection or Tom pointing to where his own call history is stored.
  5. Tomorrow Receive Xero Account Transactions exports (Cloudworkz FY23/24 & FY24/25, XLR8 FY24/25 & FY25/26, Unlock Period 2) and build the itemized R&D payment list from them, as a Cowork/Code tool (Section 9), not done manually.
  6. Gate Establish the genuine group-wide R&D potential (Section 8) — required before any further spend is committed to pursuing R&D claims. Sits ahead of any new accountant/admin spend on R&D, per the spending gate.
  7. Open Build a per-entity status-and-calendar view: last accounts submitted, next accounts due, when they can be submitted, and estimated R&D potential, for each of the five entities.
  8. Open Confirm cash at hand (tier 1 of the truth hierarchy) across all five entities today, including entering Kurai's £105k Wise balance as an actual ledger line.
  9. Open Identify and centralize bank statements for every entity across all banks in one folder — or pull equivalent data from Xero — since Cloudworkz's on-file statements turned out to be Tom's personal account, not usable as-is (Section 7).
  10. Open Once Yachay and Kurai are actually connected to Xero and have payment activity (neither is true yet, Section 6), pull their extracts and combine all five entities into a single combined spreadsheet/artifact.
  11. Open Build a clear, group-wide picture of all intercompany transfers, and a description of the relationships between entities that aligns with what HMRC were told when accounts were submitted (Section 8/9).
  12. Open Scope and build the actual financial control system (Section 6) — weekly, bank-account-level, cost-center-structured, with a forward cash view, matching the bar set by the reference wireframe. Depends on a banking connector or statement exports and Tom/William agreeing the cost-center structure, including the A2Z Data → Yachay/Kurai remapping. Distinct from, and bigger than, the snapshot extract and weekly pulse already delivered.
  13. Open Agree the updated cost-center structure with Tom/William — replace "A2Z Data/VQL" with the current entity set (Cloudworkz, Unlock, XLR8, Yachay, Kurai) in any cost-center-based reporting (Section 6).
  14. Open Apply the new revenue/fund provenance plan (Section 9) to Cloudworkz's and Unlock's investment inflows specifically, as a first pass, given both currently risk being booked as income.
  15. Open Locate William's two Wise-routing columns on the "Paid & Projected" sheet (single-tab Drive-read limitation) and fix the accidental column-hide on that tab.
  16. Open Companies House numbers still missing for Unlock, Yachay, Kurai.
  17. Open Start the §3.8-equivalent CRAFT-style multi-agent audit of this document, once Tom's existing CRAFT framework is retrieved.
  18. Open Move XLR8's Xero figures out of inline project notes into their own standalone extract note, for consistency with Cloudworkz's.
  19. Open Reconcile the XLR8 Ecosystem Company Details fee percentages (15% funds-raised fee / 35% required spend / 30% pre-tax profit, Section 4) against whatever Central Management/interim-XLR8 fee arrangement is actually adopted going forward.
  20. Open Read the XLR8_ScaleUp_for investors deck (Dec 2023) in full and pull in anything materially relevant to the entity register (Section 3) or the R&D/VAT workstreams — not yet done, flagged in Section 12.
  21. Done Cloudworkz's VAT-registration status — confirmed registered (Tom, 2026-07-12).
  22. Done, 2026-07-13 Vault quick-wins, done directly rather than listed: checked the live strategy source document for the sync gap flagged in Section 14 (confirmed complete, nothing lost — see Section 14), and created the missing Companies/Kurai/ vault folder.

14. Known documentation gaps (flagged, not silently resolved)

Resolved, 2026-07-13: vault sync gap checked directly, nothing was lost. The live copy of 2026-07-12-organizational-financial-strategy-plan-V1.md was re-read in full this session — it runs through §2.20, §3 (Plan/Roadmap), §4 (Operating Principles), §5 (Open Questions), §6 (Change Log), and §7 (Raw Transcript Log). The earlier flagged gap (content appearing to exist only through §2.8) was a stale/partial read from a prior session, not a real data loss.
Second pass, 2026-07-13: Tom checked this document directly against his original pasted brief and found real gaps. Restored in this pass: Section 2a (project/vault admin management, dropped entirely), Roy (person, dropped by name), the four-exec/finance-access breakdown (dropped), and the Roxi/hotlist/Marie test idea (dropped from the roadmap). A second restart-path prospect was also briefly restored in this pass and then removed again the same day, once Tom confirmed it wasn't proceeding — no mention of it remains in this document, per Tom's direct instruction. Left out deliberately, per Tom: "Acid Data" as a named term, and Lexi (the legal platform) — not restored. Litigation parties (Wolter, Hobsbawm) remain deliberately generalized to "see the vault's Litigation folder" rather than named, which looks like an intentional confidentiality choice from the first merge rather than an accidental drop, but is flagged here for Tom to confirm that's still what he wants. Lesson: a single "does the structure look complete" check (as in the paragraph above) is not the same check as "does the content match the original word for word" — both are needed when the source material genuinely changed hands (vault summary → merged HTML), and this document now reflects both checks having been run.

Resolved, 2026-07-13: Companies/Kurai/ vault folder created, mirroring Companies/Yachay/'s structure. Note: a pre-existing, misspelled, empty Companies/Yachay/Kurae/ subfolder should not be used and is flagged for cleanup.

This file merges what were previously two separate deliverables — the static strategy document and the standalone group-xero-pulse Cowork artifact — into one. If an older copy of either file is still circulating, this merged version (dated 2026-07-13, correction passes applied 2026-07-13) supersedes both.

Principle adopted 2026-07-13: anything needed in the vault (file checks, missing folders, and similar) is done directly rather than listed as a task — see the corresponding note in Section 13.

15. Source documents / provenance