Connecting DATEV with n8n: automatically archive Outlook attachments in DATEV DMS

2026-02-27

Connecting DATEV with n8n: automatically archive Outlook attachments in DATEV DMS

Connecting DATEV with n8n: automatically archive Outlook attachments in DATEV DMS

n8n is an obvious choice for many tax firms, TaxTech providers, and IT partners: process emails, validate data, call APIs, send notifications, build workflows.

With DATEV, however, things get more specific quickly.

DATEV is not simply another SaaS endpoint with a public REST API for everything. Depending on the use case, data lives in DATEV Online or in the DATEV desktop environment — there, for example, in DATEV DMS, accounting, or master data. For many firm workflows, the difficult part is therefore not the n8n logic, but controlled access to the right DATEV environment.

In this article, we look at a concrete n8n workflow:

Outlook email arrives → attachments are read → client is looked up in DATEV → file is uploaded to DATEV DMS → document is created with metadata → Slack is notified → Outlook email is marked.

This example is based on an n8n workflow using Klardaten DATEVconnect nodes: Klardaten Email to DMS on n8n.io

Who is this article for?

This article is aimed at:

  • Developers and IT teams at tax firms building workflow automations
  • TaxTech providers integrating DATEV functionality into their products
  • IT partners managing DATEV environments
  • Technical product teams and CTOs building DATEV workflows for production
  • n8n users looking to connect n8n with DATEV DMS

The article is intentionally technical. Not a step-by-step tutorial for n8n beginners, but concrete enough to understand how the workflow is structured and where the real production pitfalls lie.

The use case: automatically archive email attachments in DATEV DMS

Many tax firms still receive documents by email:

  • Contracts
  • Tax assessments
  • Reports
  • Payroll documents
  • Bank documents
  • PDF attachments from clients
  • Scans from departments
  • Exported reports from third-party systems

Manually, the process often looks like this:

  1. Open email
  2. Download attachment
  3. Search for client in DATEV
  4. Open DATEV DMS
  5. Archive document
  6. Set document type, period, description, and other fields
  7. Mark or move email
  8. Notify colleagues

This is not a complex thought process. It is repeatable work. That is exactly what n8n is suited for.

But: production DATEV DMS automation is more than "uploading a PDF". The workflow needs to know which client the document belongs to, which metadata should be set, and under which DATEV user context the access takes place.

Workflow architecture

The example workflow involves these systems:

Microsoft Outlook
      ↓
n8n
      ↓
Klardaten DATEVconnect Nodes
      ↓
Klardaten DATEVconnect Gateway
      ↓
DATEV DMS
      ↓
Slack / Outlook Update

The roles are clearly separated:

  • Outlook provides the email and attachments.
  • n8n controls the workflow logic.
  • Klardaten DATEVconnect Nodes encapsulate the DATEVconnect calls within n8n.
  • DATEVconnect Gateway provides access to DATEVconnect.
  • DATEV DMS stores the file and document entry.
  • Slack optionally reports success or status.
  • Outlook is updated at the end so the email is not processed again.

Workflow overview

The workflow is called:

Klardaten Email to DMS

The template is available directly on n8n.io: Klardaten Email to DMS

It contains these functional steps:

  1. A new Outlook email is detected.
  2. The workflow checks whether attachments are present.
  3. A DATEV client is looked up.
  4. Attachments are processed individually.
  5. Each file is uploaded as a document file in DATEV DMS.
  6. The current DATEV user is retrieved.
  7. File, client, and user are combined via a Merge node.
  8. A DATEV DMS document entry is created.
  9. Slack optionally receives a message.
  10. The Outlook email is marked with a category.

Technically, the workflow consists of these key nodes:

Node Type Task
New Outlook email trigger Microsoft Outlook Trigger Polls for new Outlook emails and downloads attachments
If we have attachments IF Node Lets only emails with attachments proceed
Client lookup Klardaten DATEVconnect Master Data Searches for a DATEV client
Split attachments Code Node Converts multiple attachments into individual n8n items
Upload a document file Klardaten DATEVconnect Document Management Uploads the binary file to DATEV DMS
Get DATEV user Klardaten DATEVconnect IAM Retrieves the current DATEV user
Merge Merge Node Combines file, client, and user
Create a document Klardaten DATEVconnect Document Management Creates the document entry in DATEV DMS
Send a message Slack Node Sends a notification
Update a message Microsoft Outlook Node Marks the email in Outlook

Step 1: Outlook trigger

The workflow starts with a Microsoft Outlook trigger:

{
  "type": "n8n-nodes-base.microsoftOutlookTrigger",
  "pollTimes": {
    "item": [
      {
        "mode": "everyMinute"
      }
    ]
  },
  "options": {
    "attachmentsPrefix": "attachment_",
    "downloadAttachments": true
  }
}

Two settings are important here:

"downloadAttachments": true

This causes n8n to download attachments directly as binary data.

"attachmentsPrefix": "attachment_"

This gives the binary data names such as:

attachment_0
attachment_1
attachment_2

This matters because the later code node iterates over all binary keys and creates individual items from them.

Technical note on attachment filtering

The Outlook trigger JSON includes:

"filters": {
  "hasAttachments": false
}

However, the IF node then checks:

{{ $json.hasAttachments }}

and only lets true through.

This is something to review before going to production.

There are two clean variants:

Variant A: Outlook trigger already filters for emails with attachments

The trigger should be configured so that only emails with attachments arrive. The IF node then acts as an additional safeguard.

Variant B: Outlook trigger fetches all emails

The IF node then handles the actual filtering logic.

For production use or a published template, this configuration should be clarified and cleaned up. The functional intent is clear: emails without attachments should not be processed further. The trigger configuration should reflect that.

Step 2: IF node checks for attachments

The node If we have attachments checks:

{{ $json.hasAttachments }}

The condition is: boolean equals true.

This makes sense because the workflow should only continue when attachments are actually present.

Note: the IF node has alwaysOutputData: true in the workflow.

This can be useful in n8n for debugging or controlled output. For a production workflow, check whether this is intentional. In many production automations, it is better for the false branch to end cleanly without passing unwanted items downstream.

Step 3: Look up DATEV client

The node Client lookup uses the Klardaten DATEVconnect Master Data node:

{
  "type": "@klardaten/n8n-nodes-datevconnect.masterData",
  "parameters": {
    "top": 1,
    "filter": "status eq active"
  }
}

This is intentionally a demo setup.

The workflow currently takes the first active client:

top = 1
filter = status eq active

This is sufficient for a template, but not for a production firm workflow.

In practice, client matching is the most important part of the entire workflow. DATEV DMS requires a correct client reference. If the workflow archives a document under the wrong client, the result is not automation — it is damage.

Production client matching

A production workflow should derive the client from the email. There are several strategies for this.

1. Matching by sender address

Example:

invoice@client-gmbh.de → Client GmbH

This works well when clients use fixed sender addresses.

Problem: many documents come from third parties — banks, insurers, authorities, or portals. In those cases, the sender address is not the client.

2. Matching by sender domain

Example:

*@client-gmbh.de → Client GmbH

This is more robust than individual email addresses, but still limited.

Problem: tax advisers receive many documents from domains that cannot be clearly attributed to a single client.

3. Matching by subject line

Example:

[12345] Annual financial statement 2025

or:

Client 10042 - tax assessment review

This works well when internal naming conventions are followed.

Problem: free-text subject lines are error-prone.

4. Matching via dedicated Outlook folders

Example:

Inbox/DMS/Client 10042

In this case, the folder itself is already the assignment.

This is often pragmatic — especially for firms that prefer to start semi-automatically.

5. Matching via mapping table

A mapping table might contain:

Rule DATEV client
*@client-gmbh.de Client GmbH
bank@example.com + IBAN DE... Client GmbH
Subject contains Cust No 4711 Client GmbH

This table can live in Postgres, Airtable, Google Sheets, an internal system, or a small dedicated database.

6. Review queue for uncertain assignments

Not every case should be decided automatically.

A clean production workflow usually has an intermediate state:

Client found clearly → archive automatically in DATEV DMS
Client unclear → review queue
Client not found → error channel / manual review

This is less spectacular than full automation, but far more reliable.

Step 4: Split attachments into individual items

The workflow uses a code node called Split attachments.

The code:

return $("New Outlook email trigger").all().flatMap(item => {
  const binaries = item.binary ?? {};

  return Object.keys(binaries).map(key => ({
    json: {
      ...item.json,
    },
    binary: {
      data: binaries[key],
    },
  }));
});

What happens here?

n8n stores multiple attachments from an email as multiple binary fields, for example:

attachment_0
attachment_1
attachment_2

The code takes all binary keys and creates individual n8n items from them.

An email with three attachments produces three items:

Item 1 → binary.data = attachment_0
Item 2 → binary.data = attachment_1
Item 3 → binary.data = attachment_2

This is clean because the subsequent DATEV DMS upload operates per file.

Why binary.data?

The later DATEV upload node expects:

"binaryData": "data"

That is why each attachment is explicitly mapped to the binary key data:

binary: {
  data: binaries[key],
}

This is a standard n8n technique: before an upload node, binary data is renamed to match what the upload node expects.

Step 5: Upload document file to DATEV DMS

The node Upload a document file uses the Klardaten DATEVconnect Document Management node:

{
  "resource": "documentFile",
  "operation": "upload",
  "binaryData": "data"
}

This step uploads the actual file.

Important: this is not yet the complete document entry in DATEV DMS. The upload first creates a file resource that is later referenced by the document.

The output of this node contains an ID used in the next step:

{{ $json.id }}

This ID is set as document_file_id in the document creation step.

Step 6: Retrieve the current DATEV user

Running in parallel, the node Get DATEV user:

{
  "type": "@klardaten/n8n-nodes-datevconnect.identityAndAccessManagement",
  "parameters": {
    "resource": "currentUser"
  }
}

The workflow uses the user later in the document:

"user": {
  "id": "{{ $('Get DATEV user').item.json.id }}"
}

This matters because DMS documents consist of more than just a file and a client. They also carry context information: user, domain, folder, period, and structure.

For production setups, these questions need clear answers:

  • Under which DATEV context does the access run?
  • What permissions does this user have?
  • Is this a technical service user or an actual user context?
  • Which documents may this context view or create?
  • How does this fit the firm's permission model?

In DMS, user context is not a detail. It determines visibility, access, and audit trail.

Step 7: Combine data via Merge node

The workflow uses a Merge node:

{
  "mode": "combine",
  "combineBy": "combineByPosition",
  "numberInputs": 3
}

Three inputs are combined:

  1. Current DATEV user
  2. Attachment item
  3. Uploaded document file ID

After this, the Create a document node has everything it needs:

  • Binary metadata from the attachment
  • DATEV client from Client lookup
  • DATEV user from Get DATEV user
  • Document file ID from Upload a document file

Risk with combineByPosition

combineByPosition is simple, but you need to understand what it does.

The merge combines items based on their position in the item list. This is fine as long as all inputs reliably deliver the same number and order of items.

With multiple attachments, this can get tricky if one parallel branch delivers a single item and another delivers several. In this workflow, the DATEV user is retrieved from within the attachment branch for each attachment, which keeps things aligned.

Still, test this thoroughly in production:

  • An email with one attachment
  • An email with multiple attachments
  • Multiple emails in sequence
  • Upload failure for one of several attachments
  • Empty or corrupt attachments

For critical workflows, an explicit item ID or a clean loop is sometimes more robust than a position-based merge.

Step 8: Create document in DATEV DMS

The most important node is Create a document.

It uses the Klardaten Document Management node again:

{
  "operation": "create"
}

The document is created with the following JSON:

{
  "extension": "{{ $binary.data.fileExtension }}",
  "description": "{{ $binary.data.fileName }}",
  "class": {
    "name": "Dokument",
    "id": "1"
  },
  "correspondence_partner_guid": "{{ $('Client lookup').item.json.id }}",
  "user": {
    "id": "{{ $('Get DATEV user').item.json.id }}"
  },
  "domain": {
    "name": "Mandanten",
    "id": "1"
  },
  "folder": {
    "id": "2",
    "name": "<Keine Angabe>"
  },
  "year": 2026,
  "month": 4,
  "structure_items": [
    {
      "counter": 1,
      "type": 1,
      "document_file_id": "{{ $json.id }}",
      "name": "{{ $binary.data.fileName }}",
      "parent_counter": 0,
      "creation_date": "{{ new Date().toISOString() }}",
      "last_modification_date": "{{ new Date().toISOString() }}"
    }
  ]
}

In the workflow, year, month, creation_date, and last_modification_date are dynamic:

{{ new Date().getFullYear() }}
{{ new Date().getMonth() + 1 }}
{{ new Date().toISOString() }}

The document therefore defaults to the current month and year at the time of processing.

File content and document metadata are two different things

This is important in DATEV DMS.

The workflow performs two functionally distinct steps:

1. Upload file

PDF, DOCX, XLSX, or other attachment

This step produces a document_file_id.

2. Create document entry

The document entry contains metadata:

  • File extension
  • Description
  • Document class
  • Client reference
  • User
  • Domain
  • Folder
  • Year
  • Month
  • Structure information
  • Reference to the uploaded file

Many basic automation guides overlook this distinction. In DATEV DMS, it is fundamental.

A document is not just a file. It is a file plus professional context.

Key fields in the DMS document

extension

"extension": "{{ $binary.data.fileExtension }}"

The file extension comes from the n8n binary object.

Examples:

pdf
docx
xlsx
png

description

"description": "{{ $binary.data.fileName }}"

The workflow uses the file name as the description.

This is acceptable for a template. In production, a more informative description is often better, for example:

Email attachment: Annual financial statement 2025 - Client GmbH

or:

Tax office letter - received via Outlook on 25 Apr 2026

class

"class": {
  "name": "Dokument",
  "id": "1"
}

This is the document class. It is hard-coded in the template.

In production, check which classes are appropriate for the firm's DATEV DMS setup.

correspondence_partner_guid

"correspondence_partner_guid": "{{ $('Client lookup').item.json.id }}"

This is the client or correspondence partner reference.

In the demo workflow, this value comes from the Client lookup.

In production, a random first active client must never be used here.

user

"user": {
  "id": "{{ $('Get DATEV user').item.json.id }}"
}

The workflow sets the current DATEV user.

Make sure it is clear whether this user is professionally appropriate.

domain

"domain": {
  "name": "Mandanten",
  "id": "1"
}

The template archives documents in the Mandanten context.

This fits the example use case. For other DMS structures, this must be reviewed.

folder

"folder": {
  "id": "2",
  "name": "<Keine Angabe>"
}

The template uses a generic folder.

In production, this is usually too imprecise. The folder should match the firm's archiving structure.

Examples:

  • Financial accounting
  • Payroll
  • Annual financial statements
  • Tax assessments
  • Contracts
  • Client correspondence

The correct values depend on the firm's DATEV DMS configuration.

year and month

{{ new Date().getFullYear() }}
{{ new Date().getMonth() + 1 }}

The template uses the current processing date.

This is not always professionally correct.

Example: an email arrives in April 2026 but contains a tax assessment for 2024. In that case, "current month" is likely wrong.

Better approaches:

  • Extract period from subject line
  • Use the email's sent date
  • Extract date from file name
  • Manual review queue when uncertain
  • Default to current year but flag for later review

structure_items

"structure_items": [
  {
    "counter": 1,
    "type": 1,
    "document_file_id": "{{ $json.id }}",
    "name": "{{ $binary.data.fileName }}",
    "parent_counter": 0,
    "creation_date": "{{ new Date().toISOString() }}",
    "last_modification_date": "{{ new Date().toISOString() }}"
  }
]

This links the previously uploaded file to the document.

The critical value is:

"document_file_id": "{{ $json.id }}"

Without this reference, the document entry would have no connection to the uploaded file.

Step 9: Slack notification

After successful document creation, the workflow sends a Slack message:

Created a document {{ $json.description }} from client {{ Outlook sender }} in DATEV DMS.
Email subject was {{ Outlook subject }}

This is useful for a demo.

In production, consider whether Slack is appropriate for firm data. A Slack message containing a client reference, subject line, and document description may already contain confidential information.

Better alternatives:

Variant A: Slack technical only

A DMS document was archived. Workflow ID: 12345.

No client names, no subject lines, no file names.

Variant B: Teams instead of Slack

Many tax firms use Microsoft 365. Microsoft Teams is often a better fit.

Variant C: Internal review queue

Instead of a chat notification, create an entry in an internal task list.

Variant D: Slack in test environment only

For development and demos, Slack is helpful. In production, choose the channel deliberately.

Step 10: Mark Outlook email

The final node is Update a message.

It updates the Outlook email:

"updateFields": {
  "categories": [
    "REQUEST DMS ARCHIVE"
  ]
}

This is not real archiving in the sense of moving the email to an archive folder. The workflow sets a category.

The sticky note in the template says marked as archived. But what technically happens is:

Set Outlook category

This is an important distinction.

For production use, there are several options:

Variant A: Set category

Advantage: email stays in place but is marked.

Example:

DMS_ARCHIVED

Variant B: Move email to folder

Advantage: inbox stays clean.

Example:

Inbox/Archived in DATEV

Variant C: Category plus folder move

Advantage: traceable and tidy.

Variant D: Mark only after full success

Important: the email should only be marked or moved once all attachments have been successfully processed.

In the template, the Outlook update runs after Slack. The Slack node has:

"onError": "continueRegularOutput"

This means: if Slack fails, the workflow continues anyway. This is intentional — a Slack failure should not prevent the Outlook email from being marked after a successful DMS upload.

For DATEV DMS errors, however, you should not simply continue. If the upload or document creation fails, the email must not be treated as processed.

What the workflow does well

The workflow is well structured as an example because it demonstrates several important patterns.

1. Clear separation between trigger, processing, and completion

The flow is easy to follow:

Trigger → Filter → Lookup → Split → Upload → Create → Notify → Mark

This is maintainable.

2. Multiple attachments are processed individually

This matters. Many email workflows fail because they only process the first attachment.

The code node handles this cleanly.

3. File upload and document creation are separate

This fits the DMS model better than a generic "upload PDF somewhere" approach.

4. DATEV user is retrieved explicitly

This is better than hard-coded user values.

5. Demo parts are clearly identifiable

The workflow itself signals that the Client lookup is only a demo setup.

That honesty is valuable.

What needs to be adapted before going to production

The workflow is a good template, but not a ready-made firm standard process.

These points must be adapted for production.

1. Replace client matching

Current:

"top": 1,
"filter": "status eq active"

This is demo only.

Production needs real assignment logic.

Recommendation:

Analyse email
→ find potential client
→ check uniqueness
→ only archive automatically on a clear match
→ otherwise review queue

2. Adapt DMS metadata to the firm's structure

These fields should not be used blindly:

"class": { "id": "1" }
"domain": { "id": "1" }
"folder": { "id": "2" }
"year": current year
"month": current month

In production, clarify:

  • Which document classes does the firm use?
  • What folder structure is correct?
  • Which period should be set?
  • What mandatory fields are required?
  • What description helps with later search?
  • Should the email subject be included?
  • Should the sender address be stored?
  • Should there be a reference to the original email?

3. Clean up the Outlook trigger and IF node

The intent is:

Process only emails with attachments.

The trigger configuration should be clarified and cleaned up before production use.

Either:

Trigger fetches only emails with attachments

or:

Trigger fetches all emails, IF filters for attachments

No contradictory configuration.

4. Add error paths

A production workflow needs error handling.

At minimum:

  • Upload failed
  • Document creation failed
  • Client not found
  • Multiple clients found
  • Attachment without file name
  • Unsupported file type
  • DATEVconnect unreachable
  • OAuth credential expired
  • Outlook update failed

A production workflow should have an error channel for these cases:

Error → no archive marking → notification → manual review

5. Build in idempotency

Idempotency means: if the same workflow runs twice, the same document must not appear twice in DATEV DMS.

This matters for email workflows.

Possible strategies:

  • Store Outlook message ID
  • Store attachment ID
  • Compute hash of the attachment
  • Store combination of message ID + attachment name + file size
  • Only mark processed emails after full success
  • Check for category DMS_ARCHIVED before processing

Without idempotency, duplicates appear quickly.

6. Take data privacy and professional secrecy seriously

The workflow processes firm data. This affects not just DATEV, but also Outlook, n8n, Slack, and potentially hosting.

Practical questions:

  • Where does n8n run?
  • Who has access to n8n executions?
  • Is binary data stored in n8n?
  • How long are execution logs retained?
  • What appears in Slack messages?
  • Which credentials are stored in n8n?
  • Who may edit the workflow?
  • Are there separate test and production systems?

In DATEV DMS, "it works technically" is not enough. What matters is whether the workflow fits the firm's organisation and permission model.

n8n binary mode: why the setting matters

The workflow includes:

"settings": {
  "binaryMode": "separate"
}

This is relevant for file workflows.

n8n can store binary data in different ways. For attachments, PDFs, and DMS uploads, configure binary data handling deliberately.

For production setups, these questions matter:

  • How large can attachments get?
  • Where does n8n store binary data?
  • How long are executions retained?
  • Are attachments visible in logs?
  • Are there file size limits?
  • What happens with multiple attachments per email?
  • What happens with very large PDFs?

An email attachment workflow looks small — until someone sends an email with 40 MB and 12 attachments.

DATEVconnect Gateway: why the workflow does not run directly "against DATEV"

n8n can call HTTP APIs. But DATEV is not just another arbitrary cloud service.

For DATEVconnect-based workflows, access must happen where DATEVconnect is available. That is typically a DATEV desktop environment or a suitable hosted environment.

The Klardaten DATEVconnect Gateway takes on the role of access infrastructure here.

Simplified:

n8n talks to Klardaten.
Klardaten provides controlled access to DATEVconnect.
DATEVconnect talks to the DATEV environment.

This is particularly relevant for:

  • DATEV DMS
  • DATEV accounting
  • Master data
  • Other DATEVconnect-supported areas

The advantage for n8n workflows: you do not have to build your own DATEVconnect access, local connector operation, monitoring, and error handling for each firm.

DATEV Online APIs vs. DATEVconnect

A common misconception is:

DATEV API = one API for everything

DATEV integration should not be planned that way.

For some use cases, DATEV Online APIs are relevant. For others, DATEVconnect or access to the DATEV desktop environment is required.

For this specific workflow, the target is:

Outlook attachments → DATEV DMS

When the target is DATEV DMS in a DATEV desktop / DATEVconnect environment, DATEVconnect is the relevant path.

For other scenarios — such as DATEV Unternehmen Online — the technical route may look different. So before building, always clarify first:

  1. In which DATEV product should the data land?
  2. Is the target process in DATEV DMS, accounting, master data, or DUO?
  3. Is there suitable DATEVconnect coverage for it?
  4. Is there a matching Online API?
  5. What permissions and environment requirements apply?

Typical workflow extensions

The example workflow is a good starting point. In practice, extensions tend to be added quickly.

1. Microsoft Teams instead of Slack

Many tax firms use Microsoft Teams rather than Slack.

The Slack node can be replaced by a Teams node or a Microsoft Graph call.

Important: here too, avoid writing sensitive content unnecessarily into chat messages.

2. Review queue for unclear cases

When the client cannot be identified clearly:

do not archive in DATEV DMS
→ create review task
→ team member selects client and document type
→ then DMS archiving

This is often the best approach for a productive start.

3. Automatically detect document type

You can analyse the file name, subject line, or email body.

Examples:

"assessment" in subject → document type: tax assessment
"annual statement" in file name → document type: annual financial statement
"payroll" → payroll area

For simple rules, n8n is sufficient.

For more complex classification, a separate classification step may make sense. Even then, the result should not be applied blindly when incorrect archiving would be critical.

4. Pre-filter attachments

Not every attachment belongs in DMS.

Typical exclusions:

  • Logos from email signatures
  • Small PNG/JPG images
  • .ics calendar files
  • Standard privacy notice attachments
  • Empty or corrupt files
  • Internal signature images

A production code node could filter by:

  • File size
  • File extension
  • MIME type
  • File name
  • Inline attachment flag, if available

5. Archive original email as PDF or EML

Sometimes the attachment is not enough. The email context matters.

You can additionally store:

  • Subject line
  • Sender
  • Received date
  • Email body
  • Original email as .eml
  • PDF printout of the email

Whether this makes professional sense depends on the process.

6. Duplicate detection

Before archiving in DMS, compute a hash:

SHA256(file)

Then check:

Has this file already been processed for this client?

This prevents duplicate archiving caused by repeated emails or workflow retries.

Example: production-ready flow with review queue

A more robust flow could look like this:

1. Outlook email arrives
2. Attachments are loaded
3. Signature images and irrelevant files are removed
4. Client is looked up via mapping rules
5. If exactly one client found:
   5.1 Upload file to DATEV DMS
   5.2 Create document with metadata
   5.3 Mark Outlook email as processed
6. If no client found:
   6.1 Create review task
   6.2 Mark Outlook email as "DMS review required"
7. If multiple clients found:
   7.1 Create review task
   7.2 No automatic archiving
8. On DATEV error:
   8.1 No archive marking
   8.2 Notify error channel
   8.3 Retry or manual review

This is less "magical", but production-ready.

Typical errors in DATEV n8n workflows

Error 1: The workflow only processes one attachment

Many simple workflows only take attachment_0.

The workflow shown here handles this correctly by splitting all binary attachments into individual items.

Error 2: Wrong client

This is the most critical error.

A document archived under the wrong client is worse than one that was not archived at all.

Therefore: when in doubt, use a review queue rather than automation.

Error 3: DMS metadata is too generic

When every document is archived with:

Folder: <none specified>
Description: scan.pdf
Year: current year

the workflow is technically successful but professionally poor.

Error 4: Success is reported even though DATEV failed

Slack or Outlook update must only run after a successful DATEV step.

Optional notification failures should not break the workflow. But DATEV DMS errors must be treated as hard failures.

Error 5: No duplicate detection

Outlook triggers, polling, retries, and manual restarts can all lead to multiple processing.

In production, a strategy against duplicates is required.

Error 6: n8n execution logs store too much data

For workflows involving documents, check carefully what n8n stores.

Particularly relevant:

  • Binary data
  • Execution data
  • Error logs
  • Input/output of each node
  • Retention period
  • Access to the n8n admin interface

When n8n is a good fit for DATEV workflows

n8n works well when the process is clearly scoped.

Good examples:

  • Archiving Outlook attachments in DATEV DMS
  • Transferring CRM data to DATEV master data
  • Building simple approval or review processes
  • Processing DMS documents based on external criteria
  • Notifying Slack or Teams about successful processing
  • Triggering recurring exports or imports
  • Running simple data validations before DATEV handover

n8n is particularly strong when many systems are involved:

Outlook + DATEV + Slack + internal database

or:

CRM + DATEV master data + HubSpot + Teams

When n8n alone is not enough

n8n does not automatically solve all DATEV problems.

You still need:

  • DATEVconnect access
  • Appropriate permissions
  • Working DATEV environment
  • Stable credentials
  • Firm IT coordination
  • Monitoring
  • Error handling
  • Clean client matching logic
  • Clear data and permission concepts

n8n orchestrates the workflow. It does not replace the DATEV integration.

Build vs. gateway: build it yourself or use Klardaten?

A single prototype is often quick to build.

The difficult part starts afterwards:

  • Multiple firms
  • Different DATEV environments
  • Various IT partners
  • Local installations
  • DATEVasp or PARTNERasp
  • Windows services
  • Permission issues
  • Updates
  • Monitoring
  • Support cases
  • Error analysis with real customer data
  • Rollout and operations

If you are only building an internal test, you can do much yourself.

If you want to run a production DATEV interface for multiple firms, clients, or customers, the connector operation is usually the bigger effort — not the n8n workflow itself.

The Klardaten DATEVconnect Gateway is designed exactly for this layer: access to DATEVconnect-based data and workflows, without having to build and operate the complete connector infrastructure yourself.

For the workflow shown here, this is the natural product fit:

n8n Workflow
→ Klardaten DATEVconnect Gateway
→ DATEV DMS

More: DATEVconnect Gateway

Setup checklist

For a working test, you need:

  • n8n instance
  • Microsoft Outlook OAuth2 credentials
  • Klardaten DATEVconnect credentials
  • Installed and reachable Klardaten Connector
  • Access to DATEV DMS
  • Klardaten n8n nodes
  • Test client in DATEV
  • Test mailbox or test folder in Outlook
  • Defined DMS target fields
  • Optional: Slack OAuth2 credentials
  • Test files with realistic file types

For production operation, you additionally need:

  • Real client matching
  • Error channel
  • Retry strategy
  • Duplicate detection
  • Logging concept
  • Permission concept
  • Review process for unclear cases
  • Monitoring
  • Clear responsibilities between firm, IT partner, and software provider

Technical improvements to the example workflow

If you want to make the workflow more production-ready, these adjustments are useful.

1. Configure the trigger cleanly

Either trigger only on emails with attachments, or trigger on all emails and filter via IF.

No contradictory configuration.

2. Keep node names clean

n8n expressions reference node names directly:

$("New Outlook email trigger").all()

If a node name is changed, all expressions must be updated. Therefore: set meaningful names early and avoid renaming nodes mid-workflow.

Descriptive names help in production:

Outlook - New email with attachment
DATEV - Look up client
DATEV DMS - Upload file
DATEV DMS - Create document

This makes debugging, maintenance, and onboarding easier.

3. Replace client lookup

Instead of:

"filter": "status eq active",
"top": 1

use:

Mapping rule → DATEV client ID

or:

Sender / subject / folder / external table → unique client

4. Make DMS fields configurable

Folder, class, domain, year, and month should not be hard-coded in the node if the workflow is used for multiple processes.

Better:

Configuration node
Mapping table
Environment variable
Separate lookup

5. Add error branch

n8n offers error workflows and node-level error handling.

For DATEV DMS steps, errors should never be silently ignored.

6. Reduce Slack content

Do not write unnecessary client data to Slack.

Better:

DMS archiving successful. Execution ID: ...

or a link to an internal system with access control.

7. Rename the Outlook category

Current:

REQUEST DMS ARCHIVE

This sounds more like a request than a completed status.

Better:

DMS_ARCHIVED

or:

DMS_REVIEW_REQUIRED

depending on the outcome.

FAQ

Can you connect DATEV directly with n8n?

Yes, but "directly" needs to be understood carefully. n8n can orchestrate workflows and call APIs. For DATEVconnect-based use cases, however, you need access to a DATEV environment where DATEVconnect is available. The Klardaten DATEVconnect Gateway provides that access layer.

Can n8n automatically save Outlook attachments to DATEV DMS?

Yes. The workflow shown downloads Outlook attachments, processes each attachment individually, uploads the file to DATEV DMS, and then creates the matching document entry with metadata.

What is the difference between file upload and document creation in DATEV DMS?

The file upload stores the actual binary file. Document creation creates the professional DMS entry, including client reference, description, class, folder, period, and a link to the file.

Can the workflow handle multiple attachments?

Yes. The Split attachments code node converts all binary attachments from an email into individual n8n items. Each attachment can then be processed separately in DATEV DMS.

How is the correct DATEV client found?

In the example, not yet in a production-ready way. The demo workflow takes the first active client. For production, you need your own matching logic — for example via sender address, domain, subject, Outlook folder, or a mapping table.

What happens if no client is found?

This should not run automatically in production. A review queue is better: the workflow marks the email as requiring review, and a team member assigns the client manually.

Can Slack be replaced by Microsoft Teams?

Yes. Slack is only an optional notification channel in the workflow. In many tax firms, Microsoft Teams is the more natural choice.

Should client names and subject lines be posted to Slack?

Only if this has been deliberately reviewed. It is often better to keep chat messages technical and avoid writing confidential content to Slack or Teams.

Can I use Gmail instead of Outlook?

Yes, the principle remains the same: email trigger, download attachments, split attachments, DATEV DMS upload, create document, mark email. The trigger and mail update nodes change.

Do I need DATEVconnect for this workflow?

For DATEV DMS workflows in a DATEV desktop / DATEVconnect environment, DATEVconnect is the relevant technical path. Whether DATEVconnect covers your specific case depends on the target module, the data required, and the environment.

Are DATEV Online APIs the same as DATEVconnect?

No. DATEV Online APIs and DATEVconnect solve different problems. Which interface fits depends on where the data lives and which process is being automated.

Can I use all DATEV data with n8n?

No — and that should not be claimed. Access depends on the DATEV product, API coverage, permissions, user context, and technical environment.

Is the workflow production-ready?

As a template: yes, for understanding and testing. For production, at minimum client matching, error handling, DMS metadata, idempotency, permissions, and logging must be adapted.

When do I need the Enterprise API instead of the DATEVconnect Gateway?

When DATEVconnect does not cover the required data or processes. Typical cases are deeper reporting, Power BI, controlling, or custom automations around DATEV desktop data. In those cases, check whether the Klardaten Enterprise API is a better fit.

More: Enterprise API

Summary

Connecting DATEV with n8n makes sense when the workflow is clearly scoped.

The Outlook-to-DATEV-DMS workflow shown here is a good example:

Email arrives
→ attachments are checked
→ client is looked up
→ file is uploaded
→ document is created in DATEV DMS
→ notification and Outlook marking follow

The n8n logic is not the difficult part. The real questions are:

  • How does the workflow find the right client?
  • Which DMS metadata is correct?
  • Under which user context does the DATEV access run?
  • How are errors handled?
  • How are duplicates prevented?
  • How does the workflow fit the firm's IT and permission model?

For simple tests, a template is enough. For production DATEV automation, you need a stable DATEVconnect access layer and solid operational logic.

If you want to connect n8n with DATEV DMS, master data, or accounting, the Klardaten DATEVconnect Gateway is the right starting point.

For more complex workflows, AI-powered search, or firm processes with review steps, Klarvos may be relevant as well.