Skip to main content
Not every entity runs on a cloud accounting system with an API. This example takes the file you actually get from such a system — a DATEV Kontenblatt export — and loads it into an entity in Control with one ask. The same approach works for any legacy or on-premise ledger that can only hand you a file.
The recording has narration without captions; the section below is a step-by-step text account of everything it shows. The company, figures, and account names in it are illustrative. Nothing in the video is a target or a benchmark.
  1. DATEV, or any legacy system, into Control with any AI assistant via MCP.
  2. The raw Kontenblatt export. Drop it in the chat: upload this to the German entity.
  3. It checks the granularity, full posting detail, then posts every line through Control’s MCP tools.
  4. Seven hundred seventy-two postings, January to August. Booking text, document numbers, counter-accounts.
  5. Open Control: the German entity’s P&L is live, mapped to the group chart of accounts, down to every line.
  6. Control.dev. Any ledger, any format, with any AI assistant.

​
What happens in the recording

  1. The user drops the export into the chat — a semicolon-separated Kontenblatt file with an account summary block, then every posting listed under both its account and its counter-account — and asks the client to upload it to the German entity.
  2. The client asks one question before writing anything: at what granularity? Manual transaction proposals go in batches of at most 100 rows, and each batch is approved in Control by an Owner or Admin other than the person who asked for it. The user picks full posting detail.
  3. The client proposes all 772 GL postings for January to August — booking text, posting date, document reference, and counter-account on every row — and the approved postings are what lands in Control. It reads the DATEV structure rather than summing it: the debtor and creditor sub-accounts are left out because they duplicate the AR and AP control accounts, and the opening balances come in through the Saldenvorträge postings so the balance sheet starts correctly.
  4. In Control, the entity’s P&L is live: the local SKR04 accounts land on the group chart of accounts, and every line expands down to the underlying postings.

​
Try it in your workspace

  1. Create the entity without an integration and set up its local chart of accounts, then map the local accounts to the group chart. Postings can only land on accounts that exist.
  2. Connect an AI client with MCP with write access — proposing manual transactions is a write operation, and the manual transaction tools only appear when the workspace and session allow them.
  3. Export the period from the source system and attach the file to your ask: “upload this ledger to the German entity”.
  4. Answer the granularity question deliberately. Full posting detail keeps drill-down and counterparty context; monthly balances per account are faster to approve when detail is not needed.
  5. Have an Owner or Admin who did not request the upload approve the proposed batches in Control, then open the entity’s P&L and tie the totals back to the export.

​
Read the export, do not sum it

Legacy ledger files carry structure that a naive import gets wrong. In a DATEV Kontenblatt every posting appears twice — once under each account — sub-ledger accounts mirror the control accounts they roll up to, and VAT is split across net, tax, and gross rows. The client in the recording handles all of this because it reads the file as an accountant would, and it says what it excluded and why. Ask for that explanation every time; it is your audit trail for the upload.
Example prompts: “Upload this Kontenblatt export to the DE entity at full posting detail — exclude the Personenkonten, they duplicate 1200/3300.” “Before you post, tell me the total per account and how it ties to the summary block in the file.” “Post January to August as monthly balances per account, one batch per month.”

​
Troubleshooting

​
The totals in Control are double or triple the export

The file was summed instead of read: sub-ledger rows, control-account mirrors, or both sides of each posting were loaded. Reject the batches, and ask the client to state which account groups it will load and which it will skip before proposing again.

​
Postings fail to land on an account

The local account does not exist in the entity or is not mapped to the group chart. Add it under account mappings, then ask the client to retry only the rows that failed. A batch can partially succeed: each row reports its own result and carries a stable client request ID, so re-proposing the whole batch would duplicate the rows that were already accepted.

​
The upload stops after the first batches

Each batch of up to 100 rows is a separate proposal that needs approval in Control. Approve the pending ones and let the client continue, or ask for monthly balances instead of posting detail to reduce the number of batches.

​
Next steps

Account mappings

Map the local chart of accounts before the first upload.

Manual adjustment proposals

A sample skill for investigating and proposing manual ledger entries before anything is written.

Connect an AI client

Set up MCP access with write permissions.

Adjust a budget

Put the newly loaded entity into the group plan.