Skip to main content

AI integration services that write straight into your systems

We design and build automations in which AI reads an email, invoice or spreadsheet, extracts what matters and writes the result into your CRM, accounting software or a shared folder. For every step we agree in advance where a person checks the output. We use the same methods in our own AI products, which run in live production.

  • 4 own AI products in live production
  • You own the code, scenarios and data
  • Model in the cloud or on your server
  • You talk directly to the developer
Discuss a process to automateSee the automation map

What are Webforte's AI integration services

AI integration services from Webforte cover the design, development and operation of automations in which a language model processes text, documents or spreadsheets and writes the result into a system the company already uses. Typical tasks are sorting incoming emails and enquiries, extracting data from invoices and contracts, written commentary on spreadsheet reports and searching company documents with a link to the source (RAG). Each automation has a checkpoint agreed in advance where a person approves the output whenever a mistake would cost money or client trust. The model is chosen per task: a cloud API (OpenAI, Anthropic Claude, Google) or an open-source model on the client's server when data must not leave the company. Applications are built in TypeScript and Next.js with PostgreSQL, run in Docker on a VPS or on the client's infrastructure, and the code, scenarios and data belong to the client. Webforte Technologies s.r.o. (Prague, Czech Republic, company ID 23364343) runs its own AI products Dotazio and Kurikula.ai. Pricing follows a quote after an initial consultation.

Automation map: what the AI does and where a person stays in charge

Five types of process where AI automation tends to pay off first. For each one we describe the input, what the model does, the output and the point where a person checks the result. We use this map to walk through your processes in the first consultation.

Incoming emails and enquiries

Enquiries, complaints, invoices and spam all land in a shared inbox, and someone sorts them by hand every morning. The automation reads each message, assigns a category, extracts the name, company, request and deadline, and creates a record in your CRM or a spreadsheet. For each enquiry it drafts a reply based on your template texts. Sending stays with your sales team: they edit the draft and send it. Messages the model is unsure about go to a separate folder for manual review instead of quietly ending up in the wrong category.

  • Input: messages from the shared inbox and website forms
  • AI: categorisation, data extraction, draft reply
  • Output: CRM record and a prepared draft
  • Person: edits and sends the reply

Invoice and document data extraction

PDF invoices, delivery notes or contracts are currently retyped by hand into accounting software or an ERP. Invoice data extraction takes over that work: the automation reads the document (for scans it first converts the image to text with OCR), extracts the supplier, company ID, amounts, VAT, due date and line items, and checks them against rules: does the total add up, is the supplier in the register, does the order number match. When the invoice also comes as a structured e-invoice (such as Peppol, ZUGFeRD or the Czech ISDOC format), we read the data directly and no model is needed. Anything that passes is prepared for import. Anything that fails is flagged, with the specific field that does not match. For digitising accounts payable this is usually the first step: your accounts team handles exceptions rather than retyping every line.

  • Input: PDFs, scans, e-invoices, email attachments
  • AI: reads the document and fills a fixed structure
  • Check: totals and company IDs are verified by ordinary code, not the model
  • Person: deals only with flagged exceptions

Reports from spreadsheets and exports

Every week someone downloads exports from the online shop, accounting software or ad accounts, combines them in Excel and writes a summary for management. We leave the calculations to the database and a script, because they are exact, whereas a language model can get numbers wrong. The AI receives the finished figures and writes a commentary: what changed compared with the previous period, which items stand out and what deserves a closer look. The report arrives by email or in a shared document at a fixed time. The manager reads a finished overview and decides what to do about the deviations.

  • Input: CSV exports, Google Sheets, databases
  • Calculations: SQL and scripts, not the language model
  • AI: written summary and flags on deviations
  • Person: decides on next steps

Search across company documents

Policies, price lists, data sheets and minutes sit in shared folders, and new colleagues keep asking the same questions. We build an internal search that you query in plain sentences. Technically this is RAG: the system first finds the passages in your documents that relate to the question, and only then does the model compose an answer from them. Every answer includes a link to the specific document, so it can be verified. When the source material is missing, the system says it does not know. Our product Dotazio works on the same principle.

  • Input: PDF, Word, internal wiki, shared drives
  • AI: finds relevant passages and answers only from them
  • Output: answer with a link to the source document
  • Person: document owners keep the material up to date

Drafts and documents with review

Quotes, product descriptions, tender responses or meeting minutes follow a recurring structure. The automation prepares a first version from your data: the price list, product specifications, notes from a meeting. The model gets a fixed outline and a list of facts it may use, and the output is compared with the source before it is saved. Our internal editorial pipeline for the blog, which verifies sources before publication, works the same way. A person always approves the final text, because the company is responsible for the content, not the model.

  • Input: price list, specifications, notes, template
  • AI: first version following a fixed outline
  • Check: output compared with the source facts
  • Person: edits and approves the final text

Connecting to accounting and business systems

Automation only pays off when the result lands in the system your company works in. We connect through the interface (API) the vendor officially provides. Up front we document what gets synchronised, whether one-way or two-way, and which system is the source of truth for each field. The list covers common Czech accounting and business systems, for example for a Czech subsidiary. If an interface needs an add-on module or a higher licence tier, we tell you before work starts.

PohodaImport and export of invoices, orders, contacts and stock levels in XML. POHODA mServer accepts XML requests over HTTP, so an application can write to Pohoda and read from it continuously. Two-way.
XML API and mServer
Money S3With the API add-on module an application reads data from Money S3 in real time and writes through an import queue. Without the module, exchanging XML files remains. Two-way.
API module or XML
ABRA FlexiReading and writing documents, contacts, stock and orders in JSON or XML. Webhooks report record changes, and a test save (dry run) validates a write before it is committed.
REST API
Helios iNuvioBusiness interfaces for issued and received invoices, online shop and job orders, described in the OpenAPI standard. Inuvio Server has to run on the company's side.
REST API
iDoklad and FakturoidInvoices, contacts and payments from online invoicing. Typically an online shop order or a CRM deal issues the invoice automatically and the payment status flows back. Both interfaces use OAuth 2 sign-in and webhooks (on Fakturoid, webhooks require a paid plan).
API v3
Shoptet and online shopsOrders, products, customers, stock and documents. Shoptet offers its API to add-ons and to shops on the Premium plan. WooCommerce and other platforms have their own APIs or exports.
REST API and webhooks
CRMPipedrive, HubSpot, Raynet or a custom CRM: enquiries, contacts and deals. For two-way sync we decide, field by field, which side has the final say, so changes do not overwrite each other.
REST API
When a write failsEvery request carries a unique ID, so a retry never creates a duplicate document. If the target system does not respond or rejects the record, the request stays in the queue and is retried. After repeated failures an alert arrives with the specific error, and nothing gets lost silently.
queue and alert

n8n on your server, Make, Zapier or custom code

Simpler integrations often need an automation tool rather than a custom application. We can deploy n8n as a self-hosted instance on your server or on an EU VPS rented in your company's name, so the instance belongs to you (Docker, PostgreSQL database, HTTPS, backups and updates). We can take over maintenance or hand it to your IT team. Your workflows run on your infrastructure and the data does not pass through another automation provider's cloud. We choose the tool based on where the data is allowed to live and how complex the logic is.

Swipe the table sideways to see all columns.

n8n on your server, Make, Zapier or custom codeMake or Zapiern8n on your serverCustom code
Where it runsIn the provider's cloudOn your server or an EU VPS rented in your nameOn your server or hosting
Where the data livesPasses through the provider's serviceStays on your infrastructureStays on your infrastructure
Best forQuickly connecting common cloud appsRecurring flows between systems with APIs, including AI stepsComplex logic, a custom interface, high volumes
Editing workflowsVisual editor, manageable without technical skillsVisual editor, more complex steps in JavaScriptDevelopers only
Running costsMonthly plan based on the number of operationsCommunity edition is free for internal business use, you pay for the server and maintenanceHosting and maintenance, no per-run fees
MaintenanceUpdates handled by the providerUpdates, backups and monitoring handled by us or your IT teamCode maintenance handled by us or your developer

RPA (robotic process automation) mimics a person clicking through an application following a fixed script. It suits older systems without an API, but it stops when a screen changes. AI automation can read an email or a scan and passes data through APIs, so we only reach for RPA when a system has neither an API nor an export.

How AI answers from your documents (RAG)

RAG means the system searches your documents before it answers. The model does not answer from memory but from the passages the system finds.

  1. 1

    Question

    Someone asks a question in plain language, for example: what is the complaint deadline for business customers?

  2. 2

    Search

    The system searches the pre-processed documents and selects the few passages most relevant to the question.

  3. 3

    Answer from the sources

    The model receives the question and the passages, with an instruction to answer only from them. It does not fill in anything the passages do not contain.

  4. 4

    Source link

    A link to the document is attached to the answer. If the system finds nothing relevant, it says so and offers to pass the question to a colleague.

Result: an answer you can verify in a specific document. This is how Dotazio works for municipalities and companies, and how the internal search tools we build for clients work.

How we keep AI under control

A language model is a useful tool with one property every design has to account for: it can be wrong while sounding certain. That is why we settle four things before writing the first line of code.

Hallucinations: why they happen and what helps

A hallucination is an answer that sounds plausible but is not true. The model generates likely text and has no built-in list of verified facts. So we supply the facts from outside, from your documents, database or price list, and the instructions forbid it from answering beyond them. Where possible we require the model to cite a source or a code that lets you trace the answer. Kurikula.ai, for example, backs every proposed change to a school curriculum with the code from the national curriculum framework. Output without a source is flagged or discarded.

  • The model gets facts from your data, not from memory
  • We require a source link or a traceable code
  • No source means the answer is: I don't know, not a guess
  • Output in a fixed structure (JSON) is validated by code

A human checkpoint

Before development we decide, for each automation, what happens when the AI gets it wrong. If a mistake means a misfiled email, spot checks are enough. If it means a wrong payment, a quote with the wrong price or a reply to a client on a sensitive matter, the automation only prepares the output and a person approves it. This boundary is written into the specification up front, not added after the first mistake. Every step is logged, so you can trace what the model received and what it returned.

  • The cost of a mistake sets the level of review
  • Payments, prices and sensitive communication: always approved
  • Uncertain outputs go to a manual review queue
  • Log of inputs and outputs for tracing

Deploying the model: API or your own server

A model can be used in two ways. Through a provider's API (OpenAI, Anthropic Claude, Google): you get the most capable models, pay by the volume of text processed, and data is sent to the provider for processing. Or as an open-source model running on your server: data never leaves your infrastructure, but you need capable hardware and the model is usually weaker on demanding tasks. We often combine the two: sensitive documents go to a local model, general text to the cloud API. We decide based on the type of data and the task.

  • Cloud API: highest quality, pay by volume
  • Local model: data stays with you
  • A combination based on how sensitive the data is
  • The application is built so the model can be swapped

GDPR and where the data lives

Before development we document which personal data the automation processes, who the processor is and where the servers physically sit. For cloud models we choose APIs and settings under which, according to the provider's contractual terms, data is not used for training, and processing in the EU where it is offered. Personal data the model does not need for the task is removed before anything is sent. The application, database and logs run in Docker on a VPS or on your own hosting, so you know where everything is. You receive the documentation as input for your data protection officer or lawyer.

  • List of personal data processed, before development
  • Removal of data the model does not need
  • Processing in the EU where the provider offers it
  • Documentation for your DPO or lawyer

Where the model runs: options compared

There is no single right choice. It depends on how sensitive the data is, how demanding the task is and the volume.

Swipe the table sideways to see all columns.

Where the model runs: options comparedCloud APIModel on your serverA combination
Quality on demanding tasksHighest availableLower, depends on model and hardwareHigh where it is needed
Where data is processedAt the model providerNever leaves your infrastructureSensitive data with you, the rest via API
Running costsPay by volume of textHardware and server operationBoth, on a smaller scale
Suited toText without sensitive data, early testsRegulated sectors, internal documentsCompanies with mixed data
Effort to get startedLowestServer needs preparingTwo parts to set up

We choose the specific model after testing on a sample of your data. The application is built so the model can be replaced later without rewriting the whole solution.

How a project runs

Each phase ends with an output you decide on. Development only starts after a test on your data.

  1. Consultation and choosing a process

    We go through your processes using the automation map and pick one with plenty of repetitive work where mistakes have manageable consequences. We find out how many cases you handle a month, who handles them today and which systems hold the data.

    Output: A chosen process and a non-binding quote

  2. Design and rules

    We describe the inputs, outputs, connected systems, model type and, above all, the human checkpoint. We document which personal data will be processed and where it will run.

    Output: A written design including the limits of the automation

  3. Test on real data

    We run a first version on a sample of your real emails, invoices or documents and review the results together. This shows where the model makes mistakes and whether the automation is worth it. If it is not, we say so now, not after months of development.

    Output: Test results and a decision on whether to continue

  4. Development and integration

    We build the application in TypeScript and Next.js with PostgreSQL and connect it to your CRM, email, accounting or online shop via API, or through n8n or Make.com scenarios where that fits. We add logging, a manual review queue and error alerts.

    Output: A working automation connected to your systems

  5. Deployment and handover

    We deploy in Docker on a VPS or on your hosting, train the people who will review the outputs, and hand over the code, scenarios, access credentials and documentation.

    Output: Live operation, documentation and access in your hands

  6. 30 days of monitoring

    For the first month we watch the log, error rate and exception queue, refine instructions and rules, and assess with you how much manual work the automation has taken over.

    Output: An operational review and a recommended next step

What you get

  • A process description with the human checkpoint marked
  • A test on a sample of your data before main development
  • An application or automation scenarios connected to your systems
  • Source code in a repository you own
  • Access to n8n or Make.com scenarios, servers and AI provider accounts
  • A log of inputs and outputs and a manual review queue
  • A description of personal data processing and data location
  • Training for the people who will use the automation
  • 30 days of monitoring after launch

Our own AI products in production

We do not only deploy AI for clients. We run products of our own, so we deal with model errors, running costs and user questions on our own services.

When we recommend AI automation and when we don't

It makes sense when

  • You regularly process emails, text or documents with no fixed format
  • Someone does the same work every day or week and mistakes can be caught by review
  • Your data sits in systems with an API, or can at least be exported
  • You want to own the code and automations and possibly develop them further yourself
  • You want a nearshore partner in the EU, in the same time zone as most of Europe, with the option to keep sensitive data on your own server

We advise against it when

  • The task is deterministic: moving data by fixed rules is cheaper and more reliable with an ordinary script, and we will write that for you instead of an AI solution
  • A mistake would have serious consequences and nobody has the capacity to review outputs
  • There are only a handful of cases a month, so development will not pay back
  • The material the AI should draw on is out of date or contradicts itself
  • You want a presentation on AI trends rather than a working automation

More projects in this service

All projects

Frequently asked questions

The price depends on how many systems are connected, whether an automation scenario is enough or a custom application is needed, and on any requirements for where data is stored. On top of one-off development come running costs for model calls, which grow with the volume of text processed, or for a server running a local model. You receive a specific figure in a quote after a free initial consultation.

A simple automation of one process, such as sorting emails or extracting invoice data, is usually ready in 1 to 2 weeks. An application connected to several systems takes roughly 3 to 6 weeks. The timeline depends mostly on access to data and systems on your side. We always start with a test on a sample of your real data, so you see first results before main development.

We choose models per task: cloud APIs from OpenAI, Anthropic Claude and Google, or open-source models running on your server. We build applications in TypeScript and Next.js with PostgreSQL and Drizzle ORM, connect them through your systems' APIs and, where it fits, n8n or Make.com scenarios. We deploy in Docker on a VPS or on your hosting, and build so the model can be swapped later.

Yes. We connect Pohoda through its XML interface: either by exchanging XML files or through POHODA mServer, which receives requests from an application over HTTP and sends back responses. Money S3 has an API add-on module for reading and writing; without it, XML exchange remains. ABRA Flexi and Helios iNuvio offer a REST API, Fakturoid and iDoklad an API in version 3. Before we start we check your licence and modules, because some interfaces require an add-on on the accounting software side.

It depends on the data and the complexity. Make or Zapier is enough to connect common cloud apps quickly, but the data passes through the provider's service. We deploy n8n on your server or an EU VPS rented in your company's name, so workflows and data stay with you, and the Community edition is free for internal business use. We choose custom code for complex logic, a custom interface or high volumes. We often combine them: n8n orchestrates the flow between systems and the more demanding steps run in a custom application.

Invoice data extraction means reading the details from incoming invoices automatically: supplier, company ID, amounts, VAT, due date and line items. From PDFs or scans they are read by OCR together with a language model, from structured e-invoices directly. Ordinary code then checks the totals and the supplier register, correct documents are prepared for import into accounting and doubtful ones are flagged for manual review. Your accounts team no longer retypes every line and only handles exceptions.

We plan for it from the start. The model gets facts from your data and is not allowed to answer beyond them, structured output is validated by ordinary code, and uncertain cases go to a manual review queue. Where a mistake would cost money or client trust, the automation only prepares the output and a person approves it. Inputs and outputs are logged, so every mistake can be traced and fixed in the rules.

RAG is an approach where the system first searches your documents for relevant passages and the model answers only from them, with a link to the source. It is useful when staff keep asking about the content of policies, price lists, manuals or contracts. You do not need it for tasks that process one document at a time, such as an invoice, or where a database can calculate the answer.

The application, database and logs run in Docker on a VPS or on your hosting. Only the text needed for the task is sent to a cloud model, and personal data the model does not need is removed beforehand. If data must not leave your company, we use an open-source model on your server. As a Czech company we work under the same EU GDPR and document the processing before development.

You do. We hand over the source code in a repository you have full access to, along with the n8n or Make.com scenarios, servers and AI provider accounts. The data stays in your database. Your own developers or another supplier can continue the work. The documentation explains how the parts fit together and where the rules and model instructions are changed.

Prague is in the Central European time zone and works under the same EU law and GDPR as the rest of the EU. Webforte is a small team: you talk directly to the developer building your automation, with no account manager in between. The code, scenarios and data are handed over to you, so you are not tied to us. A free initial consultation shows whether the collaboration fits.

For the first 30 days we monitor operation: the log, error rate and exception queue, and refine the model instructions. After that we agree on ongoing maintenance or hand everything over to your team. Maintenance mostly covers changes in connected systems, new model versions from providers and rule updates when your process changes.

Describe the process that slows you down

A few sentences are enough: what is done by hand today, how often, and which systems hold the data. We will reply with our view on whether AI, an ordinary script or neither is the right fit.

Free consultation