DataFlowr

View saved version →

---
name: cashflow-forecast
description: Produce a cashflow forecast for an Exact Online administration by delegating to DataFlowr's hosted forecasting agent, then poll it and report the timeline with its assumptions. Use when the user asks about future cash, a liquidity outlook, a 13-week forecast, runway, or what the coming months look like.
---

# Cashflow forecast

## Overview

Never extrapolate cash yourself. DataFlowr hosts a forecasting agent over a
deterministic two-layer engine: open AR/AP converted to weekly buckets by due
date, and fitted monthly P&L series reconciled — with cash as the balancing
item — into a closed monthly cash statement. No arithmetic on the money path is
done by a model, and none should be done by you.

Two tools: `forecasting_agent` runs a forecast, `forecasting_agent_status`
polls it.

## Steps

**1 — Resolve the division and the anchor.**
Call `exact_online_divisions` first. The anchor is a financial period
(`FinYear`, `FinPeriod`), the same convention the closing agent uses. Left out,
it defaults to the last completed financial period. If the tool answers
`FCST_ANCHOR_UNRESOLVED`, the administration's period table cannot prove which
calendar month a period covers — ask the user for an explicit year and period
rather than assuming one from today's date.

**2 — Run it.**
Call `forecasting_agent` with the division, the anchor and the horizon the user
asked for. It returns a correlation key (`fcst-XXXXXX`).

Where the administration maintains a budget in Exact Online, budgeted P&L cells
override the fitted values by default. Pass `use_budget: false` only if the user
explicitly wants a purely statistical forecast; if several budget scenarios
exist for a year, name one with `budget_scenario` or the budget is skipped.

**3 — Poll.**
A run past the synchronous budget comes back `running`. Poll
`forecasting_agent_status` with the key. Do not start a second run.

**4 — Report.**
Lead with the shape of the timeline — where cash troughs, and how deep. Then:

- the **crossover**: where the forecast stops being driven by real open items
  (`direct`) and starts being driven by fitted series (`fitted`), with the
  blended stretch in between;
- the **assumptions** the engine lists — DSO/DPO lags, VAT cadence, payroll wage
  tax, exclusions, any one-offs the user supplied;
- per-series **model and error** (which fit won, and its backtest MAE), and
  which months came from budget rather than a fit.

Say plainly which parts are observed and which are modelled. A forecast reported
without its assumptions is worse than no forecast.

## Hard stops

- `FCST_UNSUPPORTED_PERIOD_STRUCTURE` or `FCST_CALENDAR_UNVERIFIED` → the
  administration is not on monthly periods the engine can map. Report that; do
  not approximate.
- `FCST_BUDGET_UNAVAILABLE` → the budget could not be read. Offer to re-run with
  `use_budget: false` rather than silently dropping it.
- The forecast is read-only. Nothing here books anything.

View saved version →

---
name: dataflowr-erp
description: How to work in an Exact Online administration through the DataFlowr MCP server — resolving the division, choosing between the reporting tools and raw ledger tools, staying inside the query guardrails, and confirming before anything is written. Use whenever a request touches bookkeeping figures, customers, suppliers, invoices, VAT, projects or assets.
---

# Working in Exact Online through DataFlowr

## Overview

DataFlowr exposes one Exact Online administration as MCP tools. Reads are safe to
run; writes create real records in a live administration.

Tool names below are the MCP names. Your client may show them with a server
prefix (`mcp__…__exact_online_divisions`) — same tools.

## Resolve the division first

Almost every tool takes a `division`. It is Exact Online's internal division
**Code**, which is not the number users see.

1. Call `exact_online_divisions` before anything else.
2. Match on the company name or the HID the user mentions — never guess a Code.
3. One division? Use it without asking. Several and the request is ambiguous?
   Ask which company they mean.

## Reach for the reporting tools before the ledger

The reporting tools aggregate server-side against the RGS template tree and
return far less data than pulling lines yourself:

- `financial_report` — trial balance / balance sheet / P&L, with prior-year and
  budget columns.
- `financial_period_report` — the same figures per period, for trends.
- `financial_gl_data` — RGS-scoped GL aggregates. Use it as a **pre-check**
  before any line-level pull, to find out which accounts are worth opening.
- `financial_drilldown` — the transactions behind a report line.
- `financial_kpis`, `financial_query` — ratios and ad-hoc questions over the
  same tree.

Only drop to `exact_online_transaction_lines` and friends when you need
individual postings that a report line cannot answer.

## Query guardrails

These are enforced server-side; hitting them is a failed call, not a slow one.

- `exact_online_transaction_lines` must filter on **both** `FinancialYear` and
  `FinancialPeriod`. A year-only filter is expanded into per-period calls.
- Year and period field names differ per entity and are preserved verbatim:
  `ReportingYear`/`ReportingPeriod` on purchase and sales entries,
  `FinancialYear`/`FinancialPeriod` on transaction lines and bank, cash and
  general journal entries, `FinYear`/`FinPeriod` on financial periods.
- There is no `_get`: fetch a single record with `_list` plus an ID filter.
- Ask for the fields you need. Wide entities have a trimmed default `$select`;
  widening it costs bandwidth on every row.

## Before you write

Creates and updates hit the live administration.

1. Validate the required fields — the tool schema lists them.
2. Echo a plain-language summary of the draft (who, what, how much, which
   division) back to the user.
3. Wait for an explicit "yes". Never chain a write off an assumption, and never
   batch several writes behind one confirmation.

## Answering

State the figures you retrieved, name the period and the administration they
came from, and say when a number could not be tied out. Never compute a
financial figure from memory or fill a gap with a plausible-looking value — if a
call failed, say so.

View saved version →

---
name: month-end-close
description: Run a month-end close on an Exact Online administration by delegating to DataFlowr's hosted closing agent, then poll it, report its findings and record accept/dismiss decisions. Use when the user asks to close a period, run close checks, review a period for irregularities, or asks what is still open before closing the books.
---

# Month-end close

## Overview

Do **not** assemble a close out of individual ledger queries. DataFlowr hosts a
closing agent that runs a deterministic check battery and a ledger-wide scan for
irregularities against one shared context. Delegate to it and report what it
finds.

Four tools: `closing_agent` starts or continues a close, `closing_agent_status`
polls it, `closing_agent_report` returns the full picture, and
`closing_agent_decide` records a human decision on a finding.

## Steps

**1 — Resolve the division and the period.**
Call `exact_online_divisions` first (see the `dataflowr-erp` skill). The period
is a financial year and period (`FinYear`, `FinPeriod`), not a calendar month.
If the user did not name one, the agent defaults to the last closed period —
say which one you used.

**2 — Start the close.**
Call `closing_agent` with the division and the period. It returns a short
correlation key (`close-XXXXXX`). Keep it: every follow-up call needs it.

An ordinary close evaluates that one period. Only when the user asks for a
quarter or a whole financial year to be swept, add `period_from` (the first
period of the range, same financial year): the line-level checks and the
ledger scan then evaluate every listed period from `period_from` through
`period`, one transaction read per period, while balance checks still read
the closing balance through `period`. Say which periods were evaluated when
you report. Never widen the range on your own.

The check battery and the ledger scan both start on their own. Do not try to
trigger them.

**3 — Poll while it works.**
A close that outruns the synchronous budget comes back as `running`. Poll
`closing_agent_status` with the correlation key rather than starting a second
close — a duplicate start answers `CLOSING_RUN_IN_PROGRESS`.

Status carries intermediate results: the checks report so far and the findings
stream. Pass the `next_cursor` back as `since` to get only what is new. Narrate
progress from it instead of going silent.

**4 — Report.**
When the run is terminal, call `closing_agent_report` for the full picture and
summarise it: the verdict first, then findings by severity, then what was
decided already. Findings come from three sources — deterministic checks, the
ledger scan, and the agent's own judgment — and the report labels them; keep
that labelling, it tells the user how much to trust each one.

Watch the scan's completeness state. Only a **complete** scan lets silence mean
"nothing found"; anything else means "not looked at yet", and you must say so.

**5 — Record decisions.**
When the user accepts or dismisses a finding, call `closing_agent_decide` with
its `finding_key` and a short note. Decisions persist per close period and
survive re-runs, so re-running is a way to *prove* something was resolved rather
than to clear the slate.

## Hard stops

- No division, or a period the administration does not have → ask, do not guess.
- The run failed or stalled → report that plainly with the error the tool
  returned. Do not paper over it with a partial summary.
- The close proposes a correction booking → it needs explicit approval. Present
  the entry in full and wait; never approve on the user's behalf.