Moss DATEV integration

What a Moss to DATEV integration actually does

Moss sits at the point where money leaves the company: virtual and physical cards, supplier invoices moving through an approval workflow, employee out-of-pocket claims, mileage and per diems, and the subscriptions nobody remembers signing up for. Every one of those is a Beleg that eventually has to become a booking record in DATEV, with an account, a tax key, a cost centre, a document reference, and the receipt image attached to it.

Moss knows the merchant, the amount, the card holder, the cost centre someone selected in the app, and whether a receipt was uploaded. DATEV, and the Kanzlei working inside it, needs that expressed in accounting terms: which expense account in SKR03 or SKR04, which BU-Schlüssel, which creditor, which period, and how the collective direct debit Moss pulls from your bank account reconciles against the individual transactions it settles.

A Moss to DATEV integration closes that gap continuously instead of at month-end. It reads settled and approved items from Moss, applies your agreed coding rules, and hands DATEV a clean booking batch with the supporting documents already linked.

What data moves

Moss object / event	Becomes in DATEV	Notes
Settled card transaction	Expense booking against the Moss clearing account	Only settled items; a pending authorisation can still change amount
Receipt attached in Moss	Document image in DATEV Unternehmen online, linked to the booking	Delivered via Rechnungsdatenservice; matched by document reference
Approved supplier invoice	Creditor booking with due date and payment terms	Vendor mapped to a stable Kreditor account, not the raw merchant string
Employee reimbursement	Booking against the employee’s creditor / personal account	Payout path (Moss or payroll) agreed once and then fixed
Mileage and per diem	Separate bookings at statutory rates	Verpflegungsmehraufwand caps and meal-related reductions applied first
Cost centre / project tag	KOST1 / KOST2 fields	Must exist in DATEV cost-centre master data or the import is rejected
Moss collection / wallet top-up	Clearing-account settlement	Bank booking matched to the transactions the collection covers
VAT treatment per item	BU-Schlüssel	Domestic input tax, EU reverse charge under §13b, third country, non-deductible

The account determination rules, tax keys, creditor mapping, and clearing account are agreed once with your tax advisor and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive exports

• Pending is not settled. Hotel deposits, fuel holds, tips, and above all foreign-currency card spend settle days later at a different amount and a different rate. Export at authorisation and you book a figure that no longer exists. Only settled transactions are released, with the settled EUR amount and the original currency carried alongside it.
• The direct debit is not an expense. Moss collects card spend from your bank account as one collection covering many transactions across a date range. Booking that collection as expense double-counts everything. Transactions post individually against a Moss clearing account, and the collection clears it. If the account does not net to zero, something is wrong, and that is the point of doing it this way.
• Missing receipts, then late receipts. A transaction without a receipt that satisfies §14 UStG cannot carry an input-tax deduction. And receipts often appear after the booking has already gone out. The pipeline needs an explicit rule for both states. What it must never do is export the same transaction a second time with a different tax treatment.
• Reverse charge on card spend. A large share of card volume is foreign cloud, ads, and software. Those need §13b treatment and the matching tax key, driven by vendor country and VAT ID rather than by the rate a card holder tapped in the app.
• Merchant strings are not creditors. Card descriptors arrive as noise with store numbers and city codes baked in. Without normalisation and a mapping table, every month invents fresh creditor accounts for the same vendor and the Kanzlei cleans them up by hand.
• DATEV field rules are strict. Belegfeld 1 holds 12 characters. Cost centres have to exist in master data. A booking batch imports as a unit, so a handful of malformed rows can reject several hundred good ones. Delivering a clean batch plus a separate exception list beats a rejected import every time.
• Festschreibung. Once the Kanzlei has locked a period, a recategorisation in Moss cannot rewrite history. Late changes have to become dated correction bookings in the open period, which is a pipeline rule, not a manual habit.
• Entertainment and non-deductible spend. Restaurant spend on a company card is a 70/30 split with full input tax but partly non-deductible expense. Gifts have thresholds. These need explicit rules rather than a default expense account.

How we build and run it

We treat this as a pipeline, not a monthly export ritual. Moss transactions, invoices, and reimbursements are pulled on a schedule, filtered to settled and approved states, validated, and transformed into your agreed DATEV coding. The result is a DATEV-Format booking batch (the EXTF / DTVF structure Kanzlei-Rechnungswesen imports), or bookings plus receipt images delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where your Kanzlei prefers to work with booking proposals and documents.

The pipeline is idempotent. Every Moss item carries a stable identifier, and we keep the delivery state per item, so a retry, a re-run, or a late receipt never produces a duplicate booking. Corrections are issued as corrections. It runs on cloud-native, fully EU-hosted AWS infrastructure, which matters here more than usual: card-level spend is personal data about named employees, and keeping it in the EU keeps the AVV with your tax advisor and your GDPR position straightforward.

Then we keep it running. Monitoring, alerting, incident response, and watching for Moss and DATEV API changes are our responsibility under contract, with a named owner and an SLA. Scoping is fixed-price, so you know what the mapping work costs before it starts.

When this integration is worth building

Moss ships a DATEV export, and it is a decent one. If you run a single German entity on one Kontenrahmen with a standard Kanzlei workflow and a few hundred transactions a month, use it. We will say so rather than sell you a pipeline you do not need.

It earns its place when you consolidate several entities or Mandanten with different charts of accounts, when Moss spend also has to land in an ERP, when account determination depends on project, contract, or intercompany logic the standard export cannot express, when reverse charge and non-deductible splits are corrected by hand every month, or when the first three working days of every month go into reconciling a clearing account that should have reconciled itself.