Agentic Finance Workflows on Xero: A CFO and Project-Lead Pattern

Xero is a valuable source of finance evidence: invoices, payments, credit notes, contacts, accounts, journals, bank transactions, quotes, tracking categories, attachments, and receivables state.

It is not, by itself, a governed answer to “What is our cash exposure?”, “Which customers are driving overdue risk?”, or “Which projects are losing margin?”

Those questions require business definitions, sometimes more than one source, and an explicit freshness and currency basis. The MLX pattern is therefore:

Sync Xero evidence read-only, turn recurring definitions into approved Twin products, and let agents query those products through a governed route.

That is the current product. Direct Xero writeback is not.

The Current Xero Boundary

The connector runner retrieves supported Xero entities and lands them as organisation-scoped warehouse evidence. Depending on the target and maturity of the data pack, an agent may discover:

• curated Xero finance views;
• source-specific warehouse relations; or
• Xero entities inside connector_warehouse.raw_events.

The bundled Xero plugin is classified as a raw-source adapter. It exposes the warehouse list, describe, and read-only query tools for source-specific inspection. Its instructions explicitly prohibit fabricating tables, columns, tenant IDs, account meanings, tracking categories, or statuses.

For ordinary recurring business questions, the preferred destination is not the raw adapter. It is a published Twin product.

The current plugin does not expose Xero tools to:

• create or edit invoices;
• post manual journals;
• approve or authorise records;
• reconcile bank transactions;
• send invoices or reminders;
• update contacts or tracking categories.

An agent should not imply that a draft, approval, or idempotent write has occurred. Those capabilities do not exist in the native adapter today.

From Xero Evidence to a Governed Product

Consider receivables ageing. A raw invoice payload can expose an amount due and due date, but a board- or cash-level answer also needs:

• an as-of date;
• an approved ageing-bucket definition;
• treatment of voided and deleted invoices;
• settlement logic;
• currency handling;
• customer grouping;
• a freshness threshold;
• ownership of unresolved data gaps.

The Twin lifecycle makes those choices explicit.

1. Connect

The approved Xero connector syncs the required entities into the organisation-scoped warehouse. Connector progress and errors establish whether the evidence is current enough to use.

2. Discover

MLX proposes a candidate product from the available evidence: for example, receivables ageing by contact and currency, or monthly profit and loss by account.

The proposal identifies its sources, fields, grain, joins, filters, time semantics, and freshness expectations.

3. Review

A finance owner reviews the meaning. This is where the team decides what an overdue invoice is, which statuses are excluded, how contacts roll up, and whether mixed currencies may be compared.

The model does not approve its own interpretation.

4. Publish and validate

The approved product receives a stable relation, versioned contract, machine query policy, and validation evidence. Where the use case warrants it, a product-specific evaluation suite checks representative questions and failure cases.

5. Use

An approved agent queries the activated product through mlx_governed_product_query. It requests typed fields, filters, grouping, ordering, and limits. The runtime validates the request, injects organisation scope, and mechanically compiles a read-only query against the exact published relation.

The resulting answer can cite the product slug, version, relation, and source watermark used.

Aged Receivables: The Detail That Changes the Number

Historic receivables are a good example of why business products need explicit semantics.

A naive reconstruction starts with the invoice total and subtracts payments received by the as-of date. That is incomplete. Xero invoices can also be settled through:

• credit-note allocations;
• overpayment allocations;
• prepayment allocations.

A correct historic product subtracts every supported settlement type dated on or before the as-of date, floors the result appropriately, and excludes invoices whose status makes them ineligible.

Where a settlement view is available, the product can use it directly. Where it is not, the necessary allocations must be reconstructed from the synced evidence.

The validation check is straightforward and essential: run the same reconstruction as of today and compare it with the current invoice amount_due. If the totals do not reconcile, name the residual and do not present the historic number as settled fact.

That rule belongs in the product definition and validation evidence. It should not be rediscovered from a prompt each time a CFO asks for aged debt.

Useful Read-Only Products for a CFO

Receivables exposure

An approved receivables product can support:

• overdue balance by ageing bucket;
• concentration by contact;
• invoices approaching a material threshold;
• changes in overdue exposure between two cuts;
• supported point-in-time analysis where settlement evidence is complete.

The answer should state the as-of date, bucket basis, currency basis, and freshness watermark.

It can help a finance team prioritise action. It cannot send a chase or mark an invoice as paid through the current native adapter.

Monthly profit and loss

Where the curated Xero finance pack is available, a monthly P&L product can expose an approved account and month grain. It can support period comparisons, material movements, and management commentary.

The contract should make clear whether figures are by account, account code, month, entity, or another grain. It should also state how currency is treated.

An agent can draft commentary from that governed result. The finance owner remains responsible for the signed-off narrative.

Cash and bank-transaction visibility

Synced bank transactions and account evidence can support a bounded cash or movement product if the required sources and freshness are present.

A 13-week forecast is not automatically “in Xero.” It usually requires assumptions about collection timing, payment timing, payroll, financing, and commitments. Those assumptions must be reviewed as part of the product or supplied by another approved source.

If the evidence supports only recorded bank transactions, the product should not label the result a forecast.

Project Leads Need More Than a Xero Label

Xero tracking categories can help allocate invoices and bills, but project profitability may also require:

• time or effort from a delivery system;
• loaded labour cost;
• project budgets or estimates;
• contract or milestone state;
• an approved mapping between the Xero tracking option and the operational project.

The Twin is valuable precisely because it can govern that cross-system product.

A project-margin product might combine Xero revenue and direct costs with approved delivery evidence. Human review resolves the project mapping and margin definition before publication. The agent then queries one product rather than improvising joins between the ledger and project tool.

This preserves the distinction between:

• Xero source truth: what Xero recorded;
• operational source truth: what delivery systems recorded;
• approved business meaning: how the organisation has agreed to combine them.

Currency, Freshness, and Drill-Down

Three rules keep Xero answers honest.

Keep currency explicit

Do not sum or rank mixed currencies as though they were comparable. Use a published reporting-currency measure when the product provides one; otherwise group by currency and state the limitation.

State the freshness cut

The agent reads synced evidence, not a magical live view of Xero. A governed answer should carry the product's source watermark. If freshness is outside the contract, the safe result is a warning or refusal.

Do not invent transaction lineage

A Twin citation identifies the published product and evidence cut used. It does not automatically create a click-through to every Xero record.

If invoice-level drill-down is required, the product must preserve an appropriate source reference. Otherwise the answer should say that transaction-level evidence is not exposed by that product.

What Safe Xero Writeback Would Require

Writeback is a separate product surface, not an extension of the current read-only skill.

Before MLX could claim a native Xero write workflow, it would need:

• implemented, typed tools for specific operations;
• connector credentials with the necessary Xero scopes;
• user and tenant authority checks;
• narrow field policies;
• an explicit approval state where required;
• idempotency and duplicate prevention;
• provider error and retry handling;
• structured audit evidence;
• reconciliation and recovery tests against approved fixtures.

None of that should be inferred from the fact that the connector can read an entity.

Until those controls and tools exist, “create,” “approve,” “reconcile,” and “send” are unsupported native actions.

The Practical Starting Point

Start with one recurring read-only decision:

1. verify the required Xero entities are syncing;
2. establish their freshness and currency coverage;
3. propose a narrow Twin product;
4. review the finance definition;
5. publish it with validation evidence;
6. run representative questions through the governed agent path;
7. add an evaluation suite if the risk warrants it.

That is enough to turn Xero from a collection of source records into a governed finance answer without pretending the agent can operate the ledger.

The general ledger remains in Xero. The approved business interpretation lives in the Twin. The current MLX agent reads; a human or existing Xero workflow acts.

---

Related: Why Your Operational Reporting Is Lying to You. How a Twin product reconciles finance and operational evidence without letting the agent invent the join.

On-premises counterpart: Agentic Finance Workflows on SunSystems. The same read-only evidence-to-product pattern over a different finance source.

Engineering boundary: Letting an LLM Write SQL Against Your Warehouse Safely. The difference between the governed typed path and explicit exploratory SQL.