iManage Work

How documents get in and become findable: scanning and email intake, OCR, classification and metadata extraction, and whether incoming e-invoices (XRechnung, ZUGFeRD) are read as structured data rather than as pictures.

0 — Not a document intake tool: files cannot be uploaded or captured into the product as documents.

3 — Upload, drag-and-drop or scan import with full-text OCR; email intake, document types and field extraction are basic or not described.

5 — Scanner or app capture and email intake, full-text OCR, and document types with metadata fields, some filled automatically (date, sender, amount or similar).

8 — AI- or rule-based classification and field extraction with a validation step, XRechnung and ZUGFeRD read as structured data, mailbox and Microsoft 365 intake, and duplicate detection documented.

10 — Capture is engineered and shown: classification and extraction trainable per document type, validation queues, e-invoice validation against the standard, intake channels listed with their limits, and where AI processing runs (location, model provider) stated.

Who may see and change which document, what happened to it, and whether earlier states can be recovered: version history, check-in and check-out, role- and attribute-based rights, and an audit trail of reads and changes.

0 — A file drop without users or history: anyone with access sees and overwrites everything, by the vendor's own description.

3 — Version history and folder or workspace permissions; check-out, roles and an audit log are basic or not described.

5 — Version history with restore, users, roles or groups with rights per folder or document type, and a log of who changed or accessed documents.

8 — Check-in and check-out, metadata-driven permissions (by department, client or confidentiality), an audit trail covering reads, exports and deletions, single sign-on and directory sync (Entra ID, LDAP) documented, and administrators' own actions logged.

10 — Access is provable: the audit trail is tamper-evident and exportable, permission changes are themselves versioned, field-level rights and need-to-know access for HR or legal records documented, and the log retention period stated.

GoBD-compliant, revisionssicher archiving: immutability of archived documents, retention schedules and deletion, tax-audit data access, and the independent evidence behind the claim — scored on what is certified and documented, not on the word "GoBD-konform".

0 — Not an archive: a file store or collaboration space in which, by the vendor's own description, documents can be edited or deleted at any time and no retention function exists.

3 — "GoBD-konform" or "revisionssicher" archiving claimed, or retention mentioned; how immutability is achieved and how retention is configured are basic or not described.

5 — GoBD-compliant archiving stated with archived documents protected against change, retention periods configurable per document type, and GoBD guidance or a sample Verfahrensdokumentation offered.

8 — An auditor's report (IDW PS 880 or comparable) published or named with its scope and date, WORM or equivalent storage described, deletion after expiry and legal hold, GDPR deletion reconciled with retention duties, and Z1–Z3 tax-audit export documented.

10 — Archiving is evidenced end to end: current Testat with scope covering the cloud and on-premises editions as sold, retention and deletion logged and reportable, long-term formats (PDF/A) enforced, and a documented procedure for the tax audit and for moving the archive without breaking its integrity.

What happens to a document after it arrives: approval and invoice workflows, tasks and deadlines, and the connectors that tie the DMS to ERP, accounting, DATEV, Microsoft 365 and the rest of the stack.

0 — Storage only: the product is described as an archive or file store with no tasks, approvals or connections to other systems.

3 — An approval, sharing or task step and a few named integrations; a workflow designer and an API are basic or not described.

5 — Configurable approval or invoice workflows with tasks and deadlines, Microsoft 365 or Outlook integration, and an API or connectors to named accounting or ERP systems such as DATEV.

8 — Graphical workflow modelling without code with substitutes and escalation, invoice workflow with ERP or DATEV handover documented, connectors for named ERP systems (SAP, Microsoft Dynamics, DATEV) with their scope, a documented REST API with webhooks or events, and e-signature integration.

10 — Workflows are a platform: versioned workflow definitions, process reporting with throughput times, a public API reference with rate limits and a sandbox, a partner marketplace of integrations with stated maintainers, and workflow history kept in the audit trail.

Finding documents again and taking them with you: full-text and metadata search, saved searches and mobile access, and whether documents, metadata, versions and audit trail can be exported in documented formats when the contract ends.

0 — No search and no way to get documents out again beyond opening them one by one in the product.

3 — Full-text or file-name search and single-document download; metadata filters and bulk export are basic or not described.

5 — Full-text and metadata search with filters, web and mobile access, and documents downloadable in bulk or in their original format.

8 — Saved searches and search across versions and attachments with permissions respected, bulk export of documents with their metadata (CSV, XML or similar) and versions in a documented structure, and an import path from other DMS or file shares named.

10 — The exit is designed in: a documented complete export with schema including the audit trail, export available self-service at any time, the post-termination retrieval window and data deletion stated, and archives stored in open formats so a successor system can take them over intact.

Who the contracting entity and its owner are, where documents and their metadata are stored and processed in the cloud edition, and who the subprocessors are — including any AI provider that reads document content. Independently sourced by the sovereignty pipeline.

0 — Proven non-EU on every dimension the evidence covers: non-EU contracting entity and non-EU storage of documents, with no EU or on-premises option stated.

3 — One European element proven: an EU contracting entity, EU data centres for the cloud edition, an on-premises edition, or a published DPA, with the rest of the chain unstated.

5 — EU contracting entity and EU data centres stated for the cloud edition, or an on-premises edition, with a DPA offered; the subprocessor chain (hosting, AI processing, support) is unstated or partly non-EU.

8 — EU entity, documents and metadata stored in named EU data centres, subprocessor list with locations published, AI processing location disclosed, an on-premises or private-cloud option offered, and certifications (ISO 27001, BSI C5) published.

10 — Sovereign end to end and evidenced: European ownership, EU entity, every processing location and subprocessor European, customer-controlled keys or on-premises operation available, and certifications with their scope published.

Whether a buyer can compute the cost of a given number of users, storage and modules — including cloud versus on-premises licensing, maintenance, implementation partner fees and price increases — from public pages alone.

0 — No public prices at all; every quote comes from sales or a partner.

3 — A public "from" price or one priced edition, per user or flat.

5 — Prices per user or per edition public for the main editions with the billing period stated and the main inclusions listed.

8 — Every edition and module priced publicly, storage limits and overage stated, on-premises licence and maintenance terms given, onboarding priced, and contract term and notice period published.

10 — Complete cost computability: a configurator or price list covering users, modules, storage and deployment model, partner implementation priced or bounded, and price-increase terms on a public page.