enaio kairos implementation: rolling out AI recognition safely
An enaio kairos implementation brings enaio's AI recognition into everyday use in six steps: select training data, train document classes, define fields for data extraction, validate results against a test set, review them in a pilot and retrain continuously in operation.
AWP Consult supports this project as a certified enaio partner, from selecting the document types through training with your own documents to live operation. What the AI module itself can do is described on the enaio kairos page. This page is about how it works reliably in your company.
250+
completed projects since 2006
150+
reference customers in the DACH region
12 to 18
months average payback period
AI recognition project statusExample view
Incoming invoiceDocument class in pilot operation
Pilot
- Data
- Classes
- Fields
- Test
- Pilot
- Operation
Confidence per fieldClass threshold
Document class
Supplier
Invoice number
Service date
Gross amount
Corrections from the review step feed into retraining
Key points at a glance
01
An enaio kairos implementation is the rollout project in which the AI module of the enaio platform is trained with your own documents, connected to files, workflows and ERP, and safeguarded for everyday use with thresholds and review steps.
02
AI document recognition learns from examples. What matters, therefore, is training data from real incoming documents, clearly delimited document classes and a field catalogue that defines which values are extracted.
03
How well the recognition performs cannot be promised in general terms. It is measured per document class against a test set that was not used for training, and confirmed on real incoming documents in the pilot.
04
Every result carries a confidence value. If it falls below the threshold for the respective class, the workflow presents the document to a responsible person, and their correction feeds into retraining.
05
Under Art. 4 of the AI Act (EU) 2024/1689, companies that use AI systems have, since 2 February 2025, been required to ensure a sufficient level of AI literacy among their staff. Training the reviewers is therefore part of every project.
06
AWP Consult starts with a single document type rather than a big-bang rollout and then expands class by class.
What does an enaio kairos implementation involve?
An enaio kairos implementation covers everything that lies between the installed AI module and reliable recognition in everyday use: selecting and sequencing the document types, building the training data, shaping the document classes, the field catalogue, validation, thresholds, the review step in the workflow, connection to files and ERP, as well as training and retraining in operation. Most of the work lies in the data and the rules.
This page describes the approach. Which functions the module offers, such as classification, metadata extraction, table recognition and document separation, is set out on the enaio kairos product page. Where AI generally makes sense in document management is explained on the AI in document management page. How recognition works specifically for incoming invoices is shown on the page about automated invoice processing.
Data
Review a sample from real incoming documents, separate the training and test sets, define capture rules for corrections.
Rules
Define and sign off the document classes, field catalogue, thresholds per class and the review step in the workflow.
Connection
Map results to enaio index fields, start files and workflows, hand data over to the ERP system.
Operation
Monitor the review rate, analyse corrections, retrain in a targeted way and add new classes step by step.
See enaio kairos with your own documents
In a live demo of around 45 minutes, we show the AI recognition on documents from your inbox and discuss which document type you should start with.
How does the enaio kairos implementation work?
The enaio kairos implementation runs in six steps: analysis of document types and target process, building the training data, training classification and extraction, validation against a separate test set, a pilot with real incoming documents and operation with retraining, where each phase is signed off with a clear result. Based on AWP Consult's experience, an entry-level project with one document type typically takes 8 to 16 weeks. The exact duration depends on the number of classes and the scope of the ERP connection.
01
Analysis and target picture
We capture document types, incoming channels, volumes and downstream processes and determine which document type you start with. The criterion is the benefit: many documents of the same kind, clear fields and a downstream process that today waits on manual data entry.
02
Build the training data
From your existing documents we draw a sample that reflects the real inflow, including poor scans, multi-page documents and batches. One part is used for training, another part remains untouched as the test set.
03
Training and configuration
Document classes and fields are trained, document separation and table recognition are set up, and the results are mapped to index fields, files and the workflow in enaio.
04
Validation
The test set shows, per class and per field, what is recognised correctly and where mix-ups occur. From this we derive the thresholds and define which cases go into the review step.
05
Pilot
One area works with real incoming documents. At first, recognition runs in parallel with the existing data entry, then it takes over, and the acceptance criteria from the concept decide on go-live.
06
Operation and retraining
After the production launch, we analyse the corrections from the first weeks, retrain in a targeted way and add further classes step by step.
What training data does AI document recognition need?
AI document recognition needs training data that reflects your real inbox: sample documents per document class from different senders and time periods, with good and poor scans, single-page and multi-page documents, plus consistent labelling of the correct class and the correct field values. The quantity matters less than the variety. enaio kairos can be trained with just a few sample documents per class, and further quality comes from clean data and consistent corrections.
A sample for your inbox
Together with you, we review a sample of your documents and assess which classes are suitable to start with.
Discuss a sample +49 6104 94738-1301
Cutting document classes the right way
A document class is the unit that the model is meant to distinguish. It follows the downstream process, not the appearance: if a credit note and an invoice end up in the same workflow but are posted differently, they are two classes. If three delivery note layouts take the same path, it is one.
Classes cut too finely create mix-ups, those cut too coarsely shift the distinction into the workflow.
- Clearly distinct every class can be assigned unambiguously by people, with no need to ask
- Process-related every class triggers exactly one downstream process or filing
- With a catch-all classDocuments that fit no class have their own route for review
Practical tip
Have two people assign the same 50 documents independently. Where they disagree, the class is not clearly distinct, and the model will waver there as well.
02
The sample: variety over quantity
Training data should come from real incoming documents, not from a collection of especially nice examples. A model that has only seen clean PDF files fails on the crookedly scanned delivery note with a stamp.
The sample is split before training. A test set remains untouched and later serves solely for measurement. Only in this way does validation show how the model handles documents it has never seen before.
- different senders per class, including rare ones
- paper scans, PDF attachments and photos, where they occur in everyday use
- single-page and multi-page documents, batches with several documents
- documents from several months, so that seasonal layouts are included
Practical tip
Draw the sample at random from a complete period, not from a folder that someone has pre-sorted.
03
Field catalogue for data extraction
Before a field is trained, it is settled what it should contain. The field catalogue describes, per class, each field with its meaning, format, mandatory or optional status and its target in enaio or the ERP system.
Line-item data from tables takes more effort than header data. It pays off when the downstream process checks per line item, for example when matching a delivery note with an order.
- Meaning for example delivery note number rather than just any number at the top right
- Formatdate, amount, free text, number with a check digit
- Origin read from the document or added via master data
- Targetindex field in enaio, workflow variable or handover to the ERP system
04
Correct consistently
In operation, the model learns from corrections. These are only good training data if everyone corrects in the same way. If one person enters the invoice date and another the service date into the same field, the model learns a contradiction.
That is why a short capture guideline is part of the project: what goes into which field, and how are missing values handled? It is written with the key users and practised during training.
Practical tip
Appoint a responsible person for each class who decides on doubtful cases and maintains the guideline.
05
Data protection for training data
Training documents often contain personal data, such as names on delivery notes or details in job applications. The same rules apply to them as to the rest of the holdings: purpose limitation, access only for the project team, deletion after the project ends, where no retention obligation applies.
In SaaS operation, a data processing agreement under Art. 28 of the General Data Protection Regulation (GDPR) governs the place of processing. More on this on the page about GDPR-compliant document management.
What distinguishes classification, separation and data extraction in the project?
Classification, document separation and data extraction are three tasks with their own training data, their own metrics and their own error patterns: separation decides where a document ends, classification decides what type it is, and extraction decides which values from it go into index fields and downstream processes. Each stage builds on the previous one. If a batch is separated incorrectly, every subsequent classification is worthless.
| Task | Result | How it is measured | Typical pitfall |
|---|---|---|---|
| Document separation | A batch or an email is broken down into individual documents | Share of correctly separated documents | Attachments, reverse sides and cover sheets are recognised as a separate document or overlooked |
| Classification | Each document is given a document class with a confidence value | Correctly assigned documents per class, mix-ups between classes | Similar classes such as credit note and invoice or order and order confirmation |
| Data extraction, header data | Fields such as number, date, sender and amount | Correctly read field values per field | Several dates or numbers on one page |
| Data extraction, tables | Line items with article, quantity and price | Complete and correct line items | Tables spanning several pages, subtotals, discount lines |
Which tasks you need depends on the downstream process. For plain filing, classification with a few fields is often enough.
Not sure where to start? We help you make sense of your starting position.
How is the AI recognition validated before go-live?
The AI recognition is validated before go-live against a test set that is not part of the training: for each document class, it is counted how many documents are assigned correctly and with which classes they are confused, for each field how often the value is correct, and from these results the thresholds and the review step are derived. A single overall figure across all classes conceals where the problems lie.
A proven tool is the confusion table, also called a confusion matrix. Its rows show the actual class and its columns the recognised class. What lies on the diagonal is correct, everything off it is a mix-up, and you can see immediately which classes interfere with each other.
Measure per class
A class with many documents must not hide weak, rare classes in the average.
Two types of error
A document is either not recognised or recognised incorrectly. The second type is usually more costly, because it continues unnoticed.
Measure per field
A correctly classified document with the wrong delivery note number is still an error in the downstream process.
Acceptance criteria up front
What counts as sufficient is defined in the concept before the measurement, not after the result.
How are the confidence value and threshold set per document class?
The threshold defines, per document class, the confidence value from which a result continues without human review. It is based on the harm of a misassignment and on the checks that take place in the downstream process anyway: a wrongly filed notice of termination can cost a deadline, a wrongly assigned advertising letter cannot. Confidence values are not guaranteed hit rates. Whether a high value is reliable in your holdings is only shown by validation.
| Document class (example) | Consequence of a misassignment | Threshold | Safeguard in the downstream process |
|---|---|---|---|
| Termination, contract | Deadlines are missed, rights are lost | strict | Review by a named person, follow-up reminder |
| Incoming invoice | Incorrect posting or duplicate payment | medium | Mandatory-field, duplicate and master-data checks in the incoming invoice workflow |
| Delivery note, consignment note | Document missing from the case, query to the customer | medium | Matching against the order number from the ERP or forwarding system |
| Advertising, information | Minor effort through re-sorting | low | Spot checks |
An example without specific values. You set the thresholds per class based on validation and adjust them after the pilot.
How does the pilot operation of the AI recognition work?
In pilot operation, the AI recognition works in a defined area with real incoming documents: first it runs in parallel with the existing data entry, so that both results can be compared, then it takes over with a review step, and in the end the acceptance criteria agreed beforehand decide on go-live. In this way, the department keeps working during the project, and the rules are tested on documents that nobody hand-picked.
Parallel run
Recognition writes into its own fields, while data entry continues as before. Discrepancies show which classes or fields still need training.
Takeover with a review step
Recognition takes over, and results below the threshold go to the responsible people. Their corrections are collected for retraining.
Sign-off and go-live
Measurement is against the acceptance criteria from the concept: share of documents without review, misassignments per class, throughput time. Only then do further areas follow.
Define the pilot area and acceptance criteria
Together with you, we define which document type and which area you start with and how the success of the pilot is measured.
- One document type, one area
- Acceptance criteria before the measurement
- Effort estimate before the contract
How is enaio kairos connected to files, workflow and ERP?
enaio kairos is connected by mapping the recognised class and the extracted fields to index fields in enaio, which trigger filing in the correct file and the appropriate workflow and are handed over from there to the ERP system. Users work with the dashlet directly in enaio; as a backend service with REST interfaces, kairos also serves other applications.
For handover to SAP, DATEV, Microsoft Dynamics 365, proALPHA or Sage we use the existing enaio interfaces. Master data such as suppliers, customers or order numbers comes from the ERP system and at the same time serves as a plausibility check: an extracted order number that does not exist in the ERP is a case for the review step. How tasks, deadlines and deputies are controlled in the review step is described on the workflow management page.
Index fields
Every field from the field catalogue has a target in enaio. Fields without a target are not trained.
Files
The class determines the file and register, such as supplier file, personnel file or shipment file.
Workflow
Documents above the threshold start the downstream process, documents below it land in the review basket.
Deployment model enaio kairos runs as SaaS or on-premises. The choice affects the data protection agreement and the infrastructure, not the approach.
Do you have a specific question about your situation?
What does operating the AI recognition after go-live involve?
Operating the AI recognition after go-live involves four routines: monitoring the review rate per class, analysing corrections and retraining in a targeted way, taking on new layouts and classes in an orderly manner, and measuring changes to the model against the test set before release. Without these routines, quality declines gradually, for example when suppliers change their layouts. AWP Consult supports this optimisation beyond enaio support with regular evaluations.
Monitor the review rate
If the share in the review step rises for a class, the inflow has usually changed: a new sender, a new layout, a different scanner.
Retraining from corrections
Corrections are collected, checked for consistency and used for retraining at fixed intervals.
Take on new classes
Further document types follow the same pattern: sample, training, validation, a short pilot. In this way, recognition grows class by class.
Changes kept traceable
New model versions, thresholds and classes are documented with a date. This makes it possible to show which rule applied at the time of a given processing.
We show you how this looks with enaio in your organisation.
Schedule an appointment +49 6104 94738-13What needs to be considered for data protection, works council and the AI Act?
For AI recognition in the inbox, four sets of rules apply: the GDPR with data processing and the prohibition of decisions based solely on automated processing that have legal effect, the co-determination of the works council for technical equipment, AI literacy under the AI Act, and the GoBD with procedural documentation and an internal control system. None of these prevents the project, but all of them belong in the concept.
Classifying and extracting documents is not among the high-risk areas in Annex III of the AI Act. More on this and on the deadlines of the AI Act is explained on the AI in document management page.
Art. 22 GDPR
No one has to be subject to a decision based solely on automated processing that has legal effect. Recognition prepares the data; the decision is made within the process.
§ 87 (1) no. 6 BetrVG
Correction logs show who processed which document and when. Where a works council exists, the introduction is therefore subject to co-determination as a rule.
Art. 4 AI Act
Anyone who uses AI systems ensures sufficient AI literacy among employees, for example by training the reviewers.
GoBD
For tax-relevant documents, the procedural documentation describes classes, thresholds and the review step as part of the internal control system. The original remains archived unchanged, as in a GoBD-compliant DMS.
Which mistakes slow down an enaio kairos implementation?
An enaio kairos implementation is most often slowed down by polished training data, blurry classes, a missing test set, uniform thresholds for all classes, inconsistent corrections and a start with all document types at once. None of these mistakes lies with the software. All of them can be avoided in the concept.
01
Training only on clean examples
- Consequence
- In everyday use, recognition fails on poor scans, stamps and multi-page documents.
- Better
- Draw the sample at random from a complete period, deliberately including difficult cases.
02
Classes by appearance instead of by process
- Consequence
- Many similar classes are confused, even though they take the same path.
- Better
- Align classes with the downstream process and check their distinctness with the department.
03
Measuring with training data
- Consequence
- Validation looks good, but in the pilot the figures drop significantly.
- Better
- Separate the test set before training and use it only for measurement.
04
One threshold for all classes
- Consequence
- Critical documents pass through unchecked, or harmless ones land in the review basket in large numbers.
- Better
- Set the threshold per class according to the harm of a misassignment.
05
Corrections without a guideline
- Consequence
- The model learns contradictory examples, and recognition gets worse rather than better.
- Better
- Write a capture guideline with key users, and have a responsible person decide on doubtful cases.
06
All document types at once
- Consequence
- A long project duration, late results and error causes that are hard to track down.
- Better
- Start with the document type that brings the greatest benefit and add further classes after the pilot.
Not sure where to start? We help you make sense of your starting position.
Checklist: is your company ready for AI recognition?
With this checklist you can check, before the project starts, before the pilot and before go-live, whether the conditions for reliable AI recognition are in place. General checkpoints for any document project are provided in our DMS implementation checklist.
01
Before training
- Starting document type selected by volume and benefit
- Document classes aligned with the downstream process and clearly distinct
- Field catalogue with meaning, format and target per field
- Sample from real incoming documents of a complete period
- Test set separated and locked
- Data protection and deployment model clarified
02
Before the pilot
- Acceptance criteria per class set out in writing
- Thresholds per class derived from validation
- Review step in the workflow with responsibilities and deputies
- Capture guideline for corrections agreed
- Key users and reviewers trained
- Works council involved, where one exists
03
Before go-live
- Pilot results checked against the acceptance criteria
- Handover to files and ERP tested with real data
- Procedural documentation extended with classes and thresholds
- Routine for evaluation and retraining agreed
- Sequence of the next classes planned
Frequently asked questions about enaio kairos implementation
What is enaio kairos?
enaio kairos is the AI module of the enaio platform for document and inbox processes. It classifies documents based on text and layout features, extracts metadata, recognises tables and separates batches, each with confidence values. It works as a dashlet in enaio or as a backend service. The functions in detail are described on the enaio kairos page.
How does an enaio kairos implementation work?
The project follows six steps: analysis of the document types and the target process, building the training data, training and configuration, validation against a separate test set, a pilot with real incoming documents and operation with retraining. Each phase is signed off with a clear result. AWP Consult starts with one document type and adds further classes afterwards.
How long does an enaio kairos implementation take?
Based on AWP Consult's experience, an entry-level project with one document type typically takes 8 to 16 weeks. The duration depends on the number of document classes, the field catalogue, line-item data and the scope of the ERP connection. Further classes are usually quicker afterwards, because the procedures and guidelines are in place. You receive a concrete plan after the analysis.
How high is enaio kairos's recognition rate?
A blanket recognition rate cannot responsibly be promised. It depends on document quality, the variety of senders, how the classes are cut and the quantity of training data. That is why we measure per class and per field against a test set that is not part of the training, and confirm the figures in the pilot. Uncertain results go into a review step via the threshold.
How much training data does enaio kairos need?
enaio kairos can be trained with just a few sample documents per class. How many it should be in your case depends on how much the documents within a class differ from one another. More important than the quantity is the variety: different senders, poor scans, multi-page documents and batches from real incoming documents. We review the sample with you in advance.
Does enaio already need to be running before the enaio kairos rollout?
enaio kairos is a module of the enaio platform and always works together with enaio. If the use case is clearly defined, AWP Consult recommends rolling out the enaio foundation and kairos in parallel. Files, index fields and workflows are then created to fit the recognition from the outset. How the foundation is rolled out is described in the enaio implementation.
What happens to documents that the AI does not recognise with confidence?
If the confidence value is below the class threshold, the workflow presents the document to a responsible person. They check only the uncertain values, correct them according to the capture guideline and pass the document on. The corrections are collected and used for retraining. Documents that fit no class land in a separate review.
To which ERP systems does enaio kairos hand over the data?
The recognised data first goes into index fields in enaio and from there, via interfaces, to your ERP system, such as SAP, DATEV, Microsoft Dynamics 365, proALPHA or Sage. Master data from the ERP also serves the plausibility check. Which integration route fits is clarified in the analysis phase.
Does enaio kairos run in the cloud or in your own data centre?
enaio kairos can be operated as SaaS or on-premises. In your own data centre, the documents do not leave the company. In SaaS operation, a data processing agreement under Art. 28 GDPR governs the place of processing and the sub-processors. The approach in the project is the same in both cases.
Does the works council have to approve the AI recognition?
Where a works council exists, the introduction is as a rule subject to co-determination under § 87 (1) no. 6 BetrVG, because correction and processing logs are objectively capable of monitoring behaviour or performance. It is customary to have an arrangement that describes the purpose, the evaluations and access to the logs. The earlier the works council is involved, the more smoothly the pilot runs.
What does the effort of an enaio kairos implementation depend on?
The effort depends above all on the number of document classes, the scope of the field catalogue, line-item data from tables, the condition of the sample, the ERP connection and the deployment model. Added to this are training and support during operation. You receive a transparent effort estimate after an initial consultation and process review via our contact page, before any contract is signed.
Which terms around AI recognition should you know?
The key terms that come up again and again in a project between the department, IT and data protection.
- Document class
- The type of a document that the model distinguishes, such as invoice, delivery note or notice of termination. It should trigger exactly one downstream process.
- Document classification
- Assignment of a document to a document class based on text and layout, with a confidence value.
- Data extraction
- Extraction of defined fields such as number, date, sender or amount, and of table line items on request.
- Training data
- Sample documents with the correct class and the correct field values, from which the model learns.
- Test set
- The part of the sample that is not used for training and serves only for measurement.
- Confidence value
- An indication of how certain the model is about a class or a field. It is not a guaranteed hit rate.
- Threshold
- The limit per class from which a result continues without review. Below it, a human decides.
- Confusion matrix
- A table that contrasts actual and recognised classes and makes mix-ups between classes visible.
- Retraining
- Renewed training with collected and checked corrections from operation.
Start with one document type
Start with the document type that brings the greatest benefit, and only expand the AI recognition once the pilot meets the agreed criteria.
Related topics
enaio kairosFunctions of the AI module for classification and extraction.AI in document managementWhere AI makes sense in a DMS and what the AI Act requires.Automated invoice processingHow AI reads invoices, checks them and learns from corrections.OCR or AIClassic text recognition and AI recognition compared.
Sources and legal bases
The legal statements on this page are based on these sources. Reviewed as of: November 2026.
- Art. 4 AI Act (EU) 2024/1689: AI literacy Obligation of providers and deployers, in force since 2 February 2025
- Art. 22 GDPR: Automated individual decision-making No decision based solely on automated processing with legal effect
- § 87 BetrVG: Co-determination rights (1) no. 6, technical equipment for monitoring behaviour or performance
- GoBD, BMF letter of 28 November 2019 Original version, amended since. Para. 100 internal control system, para. 34 procedural documentation
- BSI: Artificial intelligence Publications on the security of AI systems, including on training data
Your AI recognition, cleanly rolled out
In the initial consultation we record your document types and show enaio kairos on your own documents. You receive a recommendation for the starting document type and pilot area, as well as a transparent effort estimate.
- In person in Dietzenbach or online
- With the department, IT and data protection
- Result: a clear project proposal
Your certified partner for audit-proof document management, ECM and DMS in the DACH region since 2006.
150+ REFERENCE CUSTOMERS IN THE DACH REGION SINCE 2006
250+ COMPLETED PROJECTS SINCE 2006
Average payback of 12 to 18 months at 40+ companies
Certified partner
enaio® Partner DACH
Investment security with a certified enaio implementation partner and 19 years of project experience.
Contact
COMPANY
SERVICES
PRODUCTS
SOLUTIONS
© AWP Consult GmbH. All rights reserved 2026 | Powered by AWP Consult GmbH
