Can MLX post or amend SunSystems journals?

No. The current connector runner queries SunSystems and the bundled SUN runtime plugin exposes read-only warehouse tools. It does not expose Journal.Import, ValidateOnly, allocation runs, analysis updates, or any other native SUN write.

Does the agent call SunSystems live for every question?

No. The connector runner queries approved SunSystems components and lands organisation-scoped evidence in the warehouse. Source-specific analysis reads that synced evidence; recurring questions should use a reviewed Twin product derived from it.

What can the current connector read?

The connector code includes query paths for journals, accounts, business units, accounting periods, balances, reference and analysis-code data, customers, suppliers, purchase invoices, and sales invoices. Actual availability depends on the configured source and successful sync.

How should SUN revenue or turnover be reported?

Use the approved account-code and sign convention, identify the accounting period and business-unit scope, and distinguish net signed value from gross movement. If those definitions are not published or the necessary account metadata is missing, the agent should state the limitation rather than infer them.

Agentic Finance Workflows on SunSystems: A Forward-Deployed Pattern

SunSystems often sits beneath years of finance process: business units, accounting periods, account codes, analysis dimensions, journals, balances, customers, suppliers, and invoice flows.

That structure makes it valuable to an agent. It also makes loose language dangerous.

The current MLX integration does not “operate SunSystems.” It queries approved source components, syncs the resulting evidence into an organisation-scoped warehouse, and lets agents analyse that evidence through read-only tools.

For recurring business questions, the Twin adds the missing layer: a human-reviewed definition that can be published, validated, versioned, and safely queried.

The Current SUN Boundary

The connector runner contains SOAP query paths for:

journals and journal lines;
chart-of-accounts records;
business units and accounting periods;
account balances;
reference components and analysis codes;
customers and suppliers;
purchase and sales invoices.

The entities available to a particular organisation depend on its SunSystems configuration, connector scope, and successful sync. Code support is not proof that every source exposes every entity.

The bundled SUN runtime plugin is a raw-source-adapter. It is intended for explicit SunSystems inspection when source-level evidence is needed. It exposes:

warehouse_list_tables;
warehouse_describe_table;
warehouse_query.

All three operate through the tenant-scoped, read-only warehouse broker.

The plugin description also sets a routing rule: do not attach the raw SUN adapter for an ordinary governed business-data question when a Twin product or the primary MLX warehouse surface is available.

What Is Not Implemented

The current native path does not expose:

Journal.Import;
ValidateOnly;
LedgerAnalysisUpdate;
AccountAllocations.Update;
AllocationRun;
direct amendment of analysis codes;
a write payload carrying the originating user's <User><Name>.

Those may be recognisable SunSystems concepts, but they are not current MLX agent tools.

An article that describes a validated correcting journal, an approved allocation run, or a bounded recoding operation as shipped behaviour would be describing a different product.

The safe current answer to “post this journal” or “move these entries to another project code” is that the native adapter is read-only.

From SUN Evidence to a Twin Product

Raw journal evidence is not yet “revenue,” “turnover,” “suspense exposure,” or “latest invoice.”

Each of those terms depends on decisions such as:

which account codes are included;
whether the measure is net signed value or gross movement;
which accounting periods constitute the year;
whether adjustment period 013 is included;
which business units are in scope;
how debit and credit indicators affect sign;
whether an invoice feed exists or journal lines are only an invoice-like proxy;
which source watermark is fresh enough.

The Twin lifecycle turns those decisions into a governed product.

Connect

The connector runner queries the approved SunSystems surface and lands evidence under the correct organisation scope. Sync progress and errors establish what evidence is actually available.

Discover

MLX proposes a candidate product using the observed SUN structures: for example, accounting revenue by period and business unit, or debtor balances at an approved cut.

Review

A finance owner reviews account ranges, period logic, sign convention, business-unit scope, labels, grain, and freshness expectations.

The model cannot promote an inferred account range into company truth.

Publish and validate

The approved product receives a stable relation, versioned contract, machine query policy, and validation evidence. A product-specific evaluation suite can be added where the use case warrants it.

Use

An approved agent queries the activated relation through the governed Twin tool. The runtime validates typed fields, filters, grouping, and ordering, injects organisation scope, and compiles a read-only query mechanically.

The answer identifies the product, version, relation, and source watermark used.

Useful Read-Only SUN Products

Accounting revenue and turnover

A governed turnover product can encode:

the approved revenue account set;
accounting-year and adjustment-period rules;
business-unit scope;
signed-value treatment;
account labels;
comparable period logic.

This avoids asking a model to guess that all credits are revenue or to treat SUM(ABS(value)) as turnover without approval.

The answer should state whether it is accounting revenue, turnover, account-code activity, or another result class.

Balances, suspense, debtors, and creditors

Balance products need an explicit period-end basis and classification. A current balance, period movement, and cumulative balance are not interchangeable.

Where the source exposes the required account and balance evidence, a product can support:

debtor and creditor positions;
suspense balances;
balance-sheet cuts;
movements between periods;
business-unit comparisons.

If account classification or period coverage is incomplete, the product should expose the gap rather than silently substitute journal activity.

Journal activity and management narratives

Synced journals can support bounded analysis by period, business unit, account code, journal number, transaction reference, and available analysis dimensions.

An agent can use an approved product to draft a management narrative about material movements. The narrative is generated; the figures and definitions come from the published relation.

The finance owner remains responsible for sign-off.

Invoice and invoice-like evidence

The connector includes purchase- and sales-invoice query paths, but source availability must be discovered for the organisation.

If a real invoice entity is available, the product can use it. If only journal evidence is available, the result must be labelled invoice-like journal evidence. A journal number and transaction reference do not become a native invoice merely because the user used the word “invoice.”

The SUN source skill explicitly prohibits silently falling back between those result types.

Cross-System Products Are Where the Twin Helps Most

SunSystems can establish ledger facts. It may not contain the full operational meaning of a project, customer, asset, or contract.

A project-margin product might combine:

SUN revenue and direct-cost postings;
an approved mapping from analysis codes to projects;
delivery effort from a project or time system;
contract or milestone state;
a reviewed cost-allocation method.

The Twin owns the reviewed relationship between those sources. The SUN adapter remains responsible only for SUN evidence.

That separation prevents an agent from treating an analysis code with a suggestive label as a verified project mapping.

Required Answer Metadata

Every SUN finance answer should state:

Source: SUN, not a different operational system or derived proxy.
Grain: journal line, account-period balance, invoice, customer, supplier, or published product grain.
Date basis: accounting period, originated date, transaction date, or another explicit basis.
Measure and sign convention: net signed base amount, gross movement, balance, or another named measure.
Account filters: the included codes or approved classification.
Business-unit filters: the exact units in scope.
Result type: turnover, accounting revenue, journal activity, invoice-like evidence, balance, suspense, debtor/creditor, or movement.
Freshness: the product or source watermark.

If one of those is unknown and material to the answer, the agent should say so.

Network Placement Is Deployment-Specific

The connector runner must reach the configured SunSystems SOAP endpoint, and the deployment must protect the associated credentials and source path.

The repository does not prove a customer-operated on-premises MLX target, a loopback deployment beside SunSystems, a dedicated private link, or self-hosted model inference. Current model routes use external providers.

For a real target, establish:

where the connector runner executes;
how it reaches the SunSystems endpoint;
which outbound model route receives context;
where synced evidence is stored;
how secrets are supplied;
which release is active;
how connector freshness and failure are monitored.

Do not turn a plausible network diagram into a current product claim.

What Safe SUN Writeback Would Require

Native writeback would be a separate implementation programme. At minimum it would need:

typed tools for named SUN operations;
user, tenant, and business-unit authority;
connector credentials permitted for those operations;
deterministic field and method policies;
validation and preview behaviour backed by the real source API;
human approval where required;
duplicate and retry handling;
structured run and source-response evidence;
bounded fixtures for success, rejection, retry, and recovery;
reconciliation showing what SunSystems actually changed.

A skill could guide such a workflow. It could not create the permission or enforce the mutation boundary by prose.

Until those tools and controls exist, the native MLX SUN path reads.

The Practical Starting Point

Start with one recurring question:

verify the necessary SUN components sync;
establish source freshness and organisation scope;
propose a narrow Twin product;
review account, period, sign, business-unit, and result-type semantics;
publish with validation evidence;
test representative questions through the governed agent path;
add evaluations for material failure modes.

That delivers useful agentic finance without pretending the agent can mutate a twenty-year-old ledger.

SunSystems remains the system of record. The Twin governs the approved interpretation. The current MLX agent reads and explains.

Cloud-ledger counterpart: Agentic Finance Workflows on Xero. The same read-only evidence-to-product pattern over a different source.

Architecture: Letting an LLM Write SQL Against Your Warehouse Safely. Why the governed Twin path avoids model-authored SQL.