Skip to main content
This example shows a complete budget workflow driven from an AI client: you attach a budget file, the client writes the monthly values into Control through MCP, you open the imported budget in Control, and you ask a follow-up question that compares the plan with actuals.
The recording has narration, and the figures, entities, and vendor names in it are illustrative. Nothing in the video is a target or a benchmark.

​
What happens in the recording

  1. The user asks a connected AI client to import a budget file. The client reads the file locally; Control never receives the file itself.
  2. The client resolves the target budget and the group accounts it will write to, then previews the change set.
  3. After confirmation, the client writes the monthly values through the Control MCP write tool.
  4. The imported budget opens in Control, where the values are ordinary budget data that any reviewer can inspect, edit, and lock.
  5. The user asks how performance compares with the plan, and the client answers from budget values and statement actuals read back through MCP.

​
Try it in your workspace

  1. Connect an AI client with MCP and confirm the session has write access.
  2. Add the budget import skill so the client previews and reconciles the write instead of importing blindly.
  3. Attach your workbook and ask the client to preview the import without writing anything.
  4. Review the proposed values, confirm the write, and open the budget in Control to verify it.
  5. Ask a follow-up question such as “How are we doing against budget?” to compare the plan with actuals.

​
Troubleshooting

​
The file structure does not match your reporting structure

The import maps each source row to a group account in Control. When the workbook is close to your statement layout, an AI client can usually propose that mapping on its own. When the workbook comes from another system, an older plan, or a model built around different account groupings, the client has little to match on and may leave rows unmapped, split one source row across several accounts, or match on name similarity alone. Treat the mapping as its own reviewed step rather than as part of the write:
  1. Ask the client to read the target structure first, using the group accounts and statement layout in Control, and to describe the structure back to you before it proposes anything.
  2. Ask it to produce a mapping table—source row, proposed group account, and its confidence—covering every row, including the rows it cannot map. Require this before any values are written.
  3. Give it the mapping rules that apply to your chart of accounts, so it is not inferring them. Useful rules include matching on account code rather than label, which source sections to ignore, how to treat subtotal and total rows, and which source rows legitimately combine into one group account.
  4. Where you are unsure how a row should map, ask for the client’s recommendation and its reasoning instead of supplying a rule. You then validate the proposal, and the confirmed decision becomes a rule for the rest of the file.
  5. Review the completed mapping table, correct it, and only then approve the preview and the write.
Keep the reviewed mapping table so later imports of the same file format start from an agreed structure instead of a fresh interpretation.
Example prompts: “Read the group accounts and the statement layout, then explain the structure you will import into.” “Map every row of the file to a group account. Show source row, proposed account, and confidence, and list everything you could not map. Do not write anything.” “For the rows you marked low confidence, tell me what you would do and why, and wait for my decision.”

​
The client proposes a mapping you cannot verify

A proposal that cannot be traced back to a source row and a group account identifier is not reviewable. Ask for the account code or identifier behind each mapped row, and reject matches made on similar names alone. Two accounts with similar labels can carry different reporting meaning.

​
The file has dimensional detail

The write tool can target group dimension items, so cost-center and similar dimensional rows are importable when they map to dimension items in Control. The mapping is a decision like the account mapping: ask the client to show which dimension item each row targets before writing. Detail that does not correspond to a group dimension item must not be aggregated away silently — ask the client to state which rows carry it and stop, so you can approve an explicit aggregation rule or enter that part of the plan in Control instead.

​
Periods or currency do not line up

Confirm the month range, the period granularity, and the currency basis before approving a write. A quarterly or annual source needs an explicit rule for spreading values across months, and a source in another currency needs an approved conversion basis. A client should not choose either on your behalf.

​
The imported values do not match the file

Ask the client to re-read the affected months and reconcile every committed value against the source, then compare monthly totals. A difference usually traces to unmapped rows, rows aggregated into one account, or subtotal rows imported alongside the detail that produced them. You can also open the budget in Control and check the same months directly.

​
Next steps

Budget import skill

The skill file behind this workflow, including its dry-run and reconciliation rules.

Budget versus actual

Compare the imported plan with actuals on a reconciled basis.

Plan and review a budget

Review, lock, and compare budget scenarios in Control.

Connect a client

Connect Claude Code, Claude Desktop, or another MCP client.