Should invoices and delivery notes go into the AI knowledge base?

No. Records such as invoices, delivery notes and bookings stay in the system of record – the ERP or the accounts – where they are reliably kept, totalled and retained. Here, the knowledge base only adds the context, for example the service report or the correspondence that explains why a case was resolved the way it was.

How many documents does a knowledge base need to get started?

There is no minimum. A good starting point is a core set of documents that covers the most common everyday questions – often a few dozen to a few hundred documents. After that, the collection keeps growing as you use it, because every unanswered question shows which document is missing next.

Do the documents have to be perfectly organised before uploading?

No, perfect filing is not a prerequisite. It is enough to weed out clearly outdated versions or mark them as superseded. Because every answer names the source document, old material soon stands out in day-to-day work and can be cleaned up where needed.

What happens to scanned documents and paper records?

Text recognition (OCR) converts scanned documents into searchable text, and you can then query them like any other document. Paper records have to be scanned first. Handwriting and very poor scans have their limits – cleanly printed service reports and manuals usually work well.

Can confidential documents such as personnel records go into the knowledge base?

In principle yes, but only with clear access rules that define who may find which content. You also need a provider that keeps the data on EU servers and does not use customer documents to train third-party AI models. If in doubt, companies start with non-sensitive collections.

Which documents belong in an AI knowledge base?

An AI knowledge base should hold documents that record knowledge: instructions, service reports, solutions to problems, checklists, standards and internal rules. Records such as invoices, delivery notes or bookings don’t belong in it – they stay in the ERP system or the accounts. The simplest rule of thumb: the ERP knows what happened – the knowledge base knows how it’s done.

In brief

Documented know-how belongs in the knowledge base: instructions, reports, solutions to problems, standards and internal rules.
Records such as invoices, delivery notes and bookings stay in the system of record – the ERP or the accounts.
The test: would someone in the team want to know how something is done or what the rules are? Then the document belongs in it.
Less obvious formats count too: email threads with solutions to problems, meeting notes and scanned service reports.
A manageable core set of documents is enough to start with; the collection then keeps growing as you use it.

How can you tell whether a document belongs in the knowledge base?

The most reliable test is simple: might someone in the team look for this document because they want to know how something is done, why something was decided the way it was, or what to do in a particular situation? If so, it belongs in the knowledge base. If, on the other hand, the document only records that a transaction took place – delivered, invoiced, booked – then it is a record and stays in the system built for it.

This distinction between know-how and transaction data sounds trivial, but in practice it prevents the most common disappointment: a knowledge base stuffed with thousands of copies of records that still can’t answer a single question about how to proceed. The value lies not in the number of documents but in the knowledge they contain.

An AI knowledge base plays to its strengths where knowledge exists as text and people need to find it by asking a question in everyday language. The guide Using ChatGPT with your own data explains how this works technically and why uploading individual files to ChatGPT is not a long-term solution.

Which documents are a good fit?

The most valuable documents are the ones people ask about most often in their everyday work. In most companies, they fall into five groups.

Instructions and manuals. Installation, operating, set-up and maintenance instructions – whether written in-house or supplied by the manufacturer. Manufacturer documents in particular often sit as PDFs somewhere on the drive, and people still hunt for them afresh on every job.

Service reports and solutions to problems. The report on how a fault at a customer’s site was fixed last year is one of the most valuable documents a company has. This kind of experience is lost if it exists only in one employee’s head. Anyone who writes down solutions – even as a short note – builds up genuine company knowledge.

Standards, checklists and templates. Quality requirements, acceptance checklists, safety briefings, standard wording for recurring letters: everything that describes how things are done properly in your company.

Internal rules. Holiday rules, expenses rules, who holds which keys, cover arrangements. Without a knowledge base, questions about these keep landing with the same two people in the office – the knowledge base answers them quickly and names the document that applies.

Project and customer knowledge. Meeting minutes, project notes and the correspondence that explains why something was agreed the way it was. A sense of proportion helps here: not every email needs to go in, but the one explaining the reasons for a special solution certainly does.

Which documents are better kept in the system of record?

The system of record is the program formally responsible for a particular type of data. For records and stock, that is usually the ERP system (enterprise resource planning – the business software for orders, stock and invoicing) or the accounts. These systems do something a knowledge base doesn’t even attempt: keep figures reliably, calculate totals, track deadlines and meet statutory retention requirements.

Belongs in the knowledge base	Stays in the system of record
Installation, operating and maintenance instructions	Invoices and payment records (accounts)
Service reports and documented fault fixes	Delivery notes and orders (ERP)
Internal rules such as holiday or expenses rules	Stock levels and item master data (ERP)
Checklists, standards and quality requirements	Outstanding items and payment reminders (accounts)
Meeting minutes and project notes	Payroll records and payroll (payroll software)
Correspondence explaining a case	Order and quotation data as a record (ERP/CRM)

There are, of course, borderline cases. A warranty case includes an invoice – that is a record and stays in the ERP. But the same case also includes the service report and the email explaining the reasons for the goodwill gesture – that is knowledge and belongs in the knowledge base. So the knowledge base doesn’t replace the ERP; it adds the why and the how that no record contains.

How do you choose the documents in practice?

Rather than spending months sorting, a pragmatic five-step approach works well:

Start with the most common questions. For one to two weeks, collect the questions people in the company actually ask – on the phone, in the workshop, in the office. This list is what you select by.
Gather the relevant documents. For each common question, collect the documents that answer it: from folders, drives and inboxes.
Weed out anything obviously outdated. There’s no need for a big clear-out – simply leave out clearly outdated versions or mark them plainly as superseded.
Include scans. Text recognition (OCR – the automatic conversion of images into searchable text) makes scanned service reports and old manuals readable, so you can query them just as well.
Test with real questions and fill the gaps. If testing reveals a gap, a document is usually missing. That isn’t a flaw in the system but the most useful pointer to which knowledge should be written down next.

What about confidential documents?

Confidentiality is no reason to leave documents out, but it does need planning. Settle two questions before adding documents: who may find this content – and where is the data stored? Clear access rules ensure, for example, that general rules are visible to everyone but internal project matters only to the team involved.

On the provider side, three commitments count: data stored on EU servers, no use of customer documents to train third-party AI models, and a source for every answer so that every statement can be checked in the original document. For particularly sensitive collections such as personnel files, the rule is: only add them once access rights have been set up properly – if in doubt, start the knowledge base with non-sensitive collections and let it grow in a controlled way.

How do you actually get started?

The tried-and-tested route starts small: a core set of documents covering the twenty most common questions, then a test phase with real questions from everyday work, then step-by-step expansion. The How it works page shows this introduction step by step – from choosing documents through the test phase to going live. The product page gives an overview of the features and data storage of junova.