> ## Documentation Index
> Fetch the complete documentation index at: https://control-dev.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Upload a DATEV ledger with an AI client
> Watch a raw DATEV Kontenblatt export become a live P&L in Control: one ask, the client parses the file, proposes the selected postings through MCP, and the entity reports alongside the rest of the group.
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](/product-docs/configuration/account-mappings). Postings can only
land on accounts that exist.
2. [Connect an AI client with MCP](/product-docs/ai/mcp-server) 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](/product-docs/configuration/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
Map the local chart of accounts before the first upload.
A sample skill for investigating and proposing manual ledger entries before anything is written.
Set up MCP access with write permissions.
Put the newly loaded entity into the group plan.