RecordTailorRecordTailor vs. Paperless-ngx — der ehrliche Vergleich.
Paperless-ngx ist als OSS-DMS im Kleinkundensegment stark und läuft lokal; RecordTailor deckt Enterprise-Anforderungen ab (SAP ArchiveLink, CMIS 1.1, Multi-Tenancy mit RLS, Workflow-Engine, produktive Agenten, MCP) und liefert Enterprise-Support samt SLA. Für Ein-Personen-Ablage bleibt Paperless-ngx solide; für regulierte Unternehmen skaliert es nicht mit.
Feature-Vergleich — nur nachprüfbare Fakten.
Stand 07/2026. Quellen: öffentlich zugängliche Produktseiten von Paperless-ngx und CloudDNA-Marktanalyse.
| Kriterium | RecordTailor | Paperless-ngx |
|---|---|---|
| KI-Klassifikation & Extraktion | Produktiv, mit Erklärbarkeit und Few-Shot-Loop | Community-Add-ons (paperless-ai u. a.) |
| KI-Agenten (produktiv, nicht Roadmap) | Vier Agenten produktiv (Inbox, Compliance, Vertrag, Rechnung), Konfidenz-Gate, Approval-Inbox | Keine Agent-Runtime im Kern |
| RAG-Chat mit Citations | Produktiv, per-Tenant Embeddings, versionsbewusst | Community-Skripte, kein Kern-Feature |
| Plain-Language-Workflows | Ein Satz → validiertes YAML → Klartext-Rückblick | Kein Workflow-Konzept im Kern |
| Lokales LLM / kein Cloud-Egress | Ollama-Default, per Tenant konfigurierbar; kein Cloud-Egress | Lokal (OSS-Prinzip, oft mit lokalem Ollama betrieben) |
| Deployment On-Premise | Docker Compose oder Kubernetes; air-gapped-fähig | Docker Compose (lokal) |
| Air-gapped Installation | Air-gapped-Installation, signierte Updates, Sigstore-Attestation | Air-gapped-Betrieb technisch möglich |
| Git-artige Dokument-Versionierung (Branch/Merge) | Branch, Diff, Merge — echte Dokument-Versionierung | Nicht vorhanden |
| Workflow-Engine (Freigabe, n-Augen, Fristen) | Light: approve/review/sign/notify, n-Augen, Fristen, Eskalation | Kein Workflow-Modul im Kern |
| GoBD-Testat / IDW PS 880 | Manipulationssichtbare Audit-Hash-Chain; IDW-PS-880-Testat auf Roadmap | Kein Testat, keine GoBD-Zertifikate |
| ISO 27001 (Anbieter) | Auf Roadmap, nicht zertifiziert | Community-Projekt, keine Anbieter-Zertifikate |
| Audit-Beweispaket (Court-Bundle mit Hash-Manifest) | Court-Bundle-Export inkl. Hash-Manifest, extern verifizierbar | Audit-Trail vorhanden; kein Court-Bundle-Export als Standard |
| Legal Hold | Legal Hold produktiv, versioniert, mit Grund | Kein Legal-Hold-Konzept im Kern |
| Retention-Enforcement | Policies-as-Code + Compliance-Agent meldet; Enforcement-Worker in Vorbereitung | Retention über Custom-Tags und externe Skripte |
| DSGVO-Erase (auch Extraktionen, Embeddings, Cache) | DSGVO-Art.-17-Erase über Content, Extraktionen, Embeddings und Cache | DSGVO-Erase über Standard-Delete; Sonderbehandlung von KI-Add-on-Nebenprodukten nicht dokumentiert |
| Verschlüsselung at rest | AES-256-GCM at rest, TLS in transit | Über Storage-Layer/Filesystem konfigurierbar; kein Standard-at-rest |
| Multi-Tenancy (Row-Level Security) | Postgres RLS pro Tenant | Ein Corpus pro Instanz; keine RLS |
| SSO / MFA / SAML / SCIM | OIDC vorbereitet; SAML/SCIM auf Roadmap | SSO nur über Reverse-Proxy-Setups |
| Hybrid-Suche (BM25 + Vektor in einer Query) | BM25 + Vektor (RRF) in einer Query | Volltext + Tags; keine Vektor-Semantik im Kern |
| SAP ArchiveLink + CMIS 1.1 | SAP ArchiveLink und CMIS 1.1 nativ | Nicht vorhanden |
| DATEV-Anbindung | DATEV-CSV produktiv; DATEVconnect-API und XRechnung/ZUGFeRD in Vorbereitung | Nicht vorhanden |
| Office- & Outlook-Add-ins | Office/Outlook-Add-ins in Vorbereitung | Community-Add-ons für Mobile/Web-Clients |
| Mail-Ingest (IMAP, .eml GoBD-konform) | IMAP-Mail-Agent, .eml GoBD-konform; Anhänge als eigene Belege | IMAP-Ingest produktiv (Community) |
| Scan-Ingest ohne Fat-Client | MFP-Scan-Ingest ohne Fat-Client, Barcode- oder KI-Trennung | Scan-Folder-Import produktiv |
| Stapelverarbeitung mit Deduplikation | Batch-Prozessor auf GPU-Cores, BLAKE3-Deduplikation, Ausreißer-Bericht | Bulk-Import + OCR |
| MCP-Server (offene KI-Schnittstelle) | Nativer MCP-Server, fünf Tools | Community-Extensions |
| Undo / Rollback von KI-Aktionen | Rückgängigmachen von Agenten-Aktionen über Versionierung | Kein Undo-Konzept für KI-Aktionen (weil kein KI-Agenten-Kern) |
| REST-API + Webhooks | REST-API mit Scoped Service-Tokens | REST-API vorhanden |
| EU-AI-Act-Protokoll exportierbar | EU-AI-Act-Protokoll als PDF exportierbar | Nicht vorhanden |
| Open-Source-Kern | Apache-2.0-Kern, keine Vendor-Lock-in-Falle | Vollständig Open Source (AGPL) |
Alle Markennamen sind Eigentum der jeweiligen Inhaber. Angaben zu Paperless-ngx stammen aus den öffentlich zugänglichen Produktseiten des Anbieters (Stand 07/2026). Roadmap-Angaben sind als „angekündigt" gekennzeichnet.
Von Paperless-ngx zu RecordTailor.
- 1
Content-Export aus Paperless-ngx
Über das Paperless-ngx-Export-Format übernehmen wir Dokumente, Tags und Metadaten. Aus Tags werden Belegart-Vorschläge; der KI-Assistent lernt aus den bisherigen Ablagemustern.
- 2
Enterprise-Interop einrichten
SAP-ArchiveLink-Endpunkt, CMIS 1.1, DATEV-CSV, MCP-Server — was Paperless-ngx nicht kann, ist im RecordTailor-Standard-Deployment enthalten. Kein Modul-Zoo.
- 3
Multi-Tenant-Struktur aufsetzen
Was bisher ein flacher Corpus war, wird zu getrennten Tenants (Standort, Mandant, Bereich) mit Row-Level-Security. Rechte werden über ACL/RLS statt über Ordner-Sichtbarkeit gesteuert.
Häufige Fragen zum Vergleich mit Paperless-ngx.
Reicht Paperless-ngx nicht?+
Für private Ablage, kleine Vereine und Ein-Personen-Buchhaltungen: ja, oft völlig ausreichend. Für Unternehmen mit SAP-Anbindung, Multi-Standort, Mandantentrennung, Workflows und GoBD-Anspruch: nein — dort ist RecordTailor der Enterprise-Aufsatz mit den Interop-Ports, die Paperless-ngx nicht mitbringt.
Ist RecordTailor auch Open Source?+
Der Kern ist Apache-2.0. Sie können den Code lesen, forken, prüfen. Was wir verkaufen, ist Enterprise-Support, die kommerzielle Distribution und die Integrationen (ArchiveLink, DATEV-CSV, MCP-Server). Kein Vendor-Lock-in: CMIS 1.1 hält die Migrationsoption zu einem Nachfolge-System offen.
Behalten wir das lokale LLM-Prinzip von Paperless?+
Ja. RecordTailor läuft im Default gegen ein lokales Ollama-Modell — keine Cloud-KI-Anfragen. Pro Tenant lässt sich der Modell-Provider konfigurieren; das On-Prem-Prinzip bleibt.