Klaaro: Schema-First Document Extraction, EU-Hosted

A Passau document-extraction API that generates its own output schema for each document class, sold to developers through SDKs, an MCP server and an n8n node.

Overview

Most products in this IDP vendor directory ask the buyer to define the fields first. Klaaro inverts that order: it classifies an uploaded file, writes a JSON schema for that document class itself, then fills it. The vendor calls the approach zero-shot configuration, and it is why a first upload returns structured records without a setup project. Teams that want control keep it, since classes and schemas can be written by hand in a versioned editor, but the default path skips the field-mapping work that usually opens an IDP deployment.

The product is new. synsugar GmbH filed the Klaaro trademark on 18 May 2026, and the Python and TypeScript SDKs both went out on 31 May 2026 at version 0.1.0. Three months of public history is what a buyer is evaluating here, and it shapes the rest of this profile: the single named customer, the missing audit reports, the version numbers on the client libraries.

Behind it sits an established consultancy. synsugar GmbH was entered in the Passau commercial register in May 2022 under HRB 11793 with €25,000 share capital, and is run by managing directors Sarah Stemmler and Sebastian Henneberg. The firm sells AI consulting and an AI workplace platform to German mid-market manufacturers, and Klaaro grew out of an extraction feature in that platform. In July 2026 the city of Passau, the surrounding district and Niederbayern-Forum e.V. named synsugar their newcomer of the year among the region's top companies. The team page lists seven people, two of them in marketing, which sets the scale of the engineering behind the API.

Click to load video from YouTube

Klaaro writes the schema before it reads the document

Every upload runs the same four stages, and one API call triggers all of them. Parsing segments the layout and routes the page to a model that turns it into text, which is the OCR step and covers scans and handwriting as well as digital files. Classification assigns the file to a document class in the dataset, or creates a class when none of the existing ones fit. The vendor documents multi-label classification, so an order confirmation that also contains an invoice can yield records for both. Schema generation then produces the field list for that class, including nested objects and arrays of objects for table structures. Extraction fills it.

The demonstration above shows the behaviour that matters here. A German Amazon invoice headed Rechnung lands in an empty dataset with no configuration, and the pipeline files it under an invoice class it created and populates a schema it wrote. Reviewers then see the source PDF beside the extracted record, correct a value in place, and leave a comment on the field for colleagues.

Two mechanisms decide whether the output is usable. When a field has no corresponding value in the document, Klaaro leaves it empty instead of inventing one, a deliberate choice against the failure mode of prompting a model directly for a fixed schema. On top of that sit deterministic validation rules the customer writes: numeric ranges, date bounds, text patterns. A value that breaks a rule is flagged rather than passed through, and flagged records wait for human review and approval before they leave the dataset. Confidence scores accompany the extracted fields.

The models are bought in rather than built. The privacy policy names Mistral for OCR and parsing and "AI providers" for classification and extraction, giving Google Gemini and OpenAI as the examples. That is the architecture of most agentic document processing products shipped in 2026, and it means accuracy is largely a question of model selection and orchestration rather than proprietary training. The vendor publishes no accuracy figure; its FAQ answers the question with "typically very high" for standard business documents, which describes the models' general behaviour rather than measuring anything. An evaluation harness in the product lets customers measure extraction quality on their own documents before going live, and that is the number worth generating.

The schema editor versions changes like a code branch

The generated schema is an editable object, and the editor around it is the part of the product a developer will recognise fastest. Fields carry a name, a description, a type and an examples list, and can be marked required or nullable. Every type comes as a scalar or an array, including objects, currency and percentage, so a line-item table becomes an array of objects. Fields reorder by drag and drop, including in and out of nested objects. An existing schema can be imported rather than written: Zod, Pydantic, JSON Schema or SQL DDL, which turns a live database definition into a document class in one paste. The same four formats come back out.

Dataset versioning is opt-in in the dataset settings, and it changes the shape of the schema-drift problem. Klaaro hashes both the schema and the pipeline configuration; editing a field on a versioned dataset moves the work onto a draft branch and leaves the main version serving production until the draft is promoted. Anyone who has kept a large extraction schema in a JSON file under Git will recognise what that replaces. Among schema-driven competitors such as Sensible and Reducto, configuration versioning of this kind remains rare.

The integration surface arrived before the customer base

Klaaro offers seven routes into the product against one named customer, and the imbalance is the strategy. The REST API sits at /api/v1 with sk_ bearer tokens, organised as teams that own datasets that own document classes. Around it: typed SDKs on npm and PyPI, an MCP server at /api/mcp over streamable HTTP with OAuth for Cursor, Claude Code and GitHub Copilot, and an official n8n community node shipping both an action node and a trigger that fires on extraction complete, failure or record update. Documents also enter by email, by URL or from Google Drive; records leave as CSV, Excel or JSON, in the dashboard or through the API, with webhooks for the asynchronous half.

Read the integrations page carefully on two of those names. Zapier and Make appear as available, but the documented setup is a webhook registration plus generic HTTP modules against /api/v1, which is the same work as calling the API from anywhere else. Only n8n has a native package.

The schema catalogue is the other half of the developer pitch: fourteen field sets for invoices, offers, order confirmations, delivery notes, price lists, purchase contracts, acceptance protocols, bills of quantities, tender notices, employment contracts, résumés, commission statements, instalment plans and energy load profiles, at nine to fifteen fields each. Those files are useful whether or not a buyer ever signs, which is presumably the point.

Use cases

Construction tenders and bills of quantities

The strongest case is the one that has nothing to do with invoices. A German Leistungsverzeichnis, the item-by-item bill of quantities attached to a tender, arrives as a structured GAEB file when the issuer is organised and as a PDF when it is not. Those PDFs run from two pages to over a thousand, vary in structure between issuers, and are read manually by estimators who copy positions into calculation software, the step before the arithmetic rather than the arithmetic itself. Klaaro targets that gap, extracting WBS codes, item descriptions, quantities, units and rates from the construction page's example documents, and ships a bill-of-quantities schema in the free catalogue. Template-based extraction handles this class of document badly, and few competitors address it at all.

Logistics and customs paperwork

Bills of lading, manifests, proofs of delivery, freight invoices, packing lists and customs documents, extracted into container numbers, seal numbers, BoL numbers and SCAC codes for an ERP. The documents are multilingual and unstandardised, which is the condition under which classify-then-generate beats a fixed template. Workist and Klippa cover neighbouring ground in the same European market.

Energy and utility documents

Power purchase agreements, grid connection agreements, utility bills, meter readings and installer quotes. The published consumption and load-profile schema shows what the resulting record looks like: meter IDs, consumption in kWh, tariffs, charges and VAT.

One number attached to all three deserves a caveat. Each industry page promises average savings of around €108,000 per year, the same figure in all three verticals, which makes it a modelled full-time-equivalent salary rather than a measured customer outcome.

The EU-hosting claim needs a closer read

The homepage carries three badges, GDPR compliant, EU Hosting and Based in Germany, and the security section states that "all data processing and storage happens on EU servers. Your data never leaves Europe." The privacy policy describes something more nuanced. Its subprocessor list names Vercel for hosting, blob storage and analytics, located in the United States "subject to appropriate safeguards"; Supabase for authentication, database and storage, qualified as "EU/EEA where available"; Mistral for OCR and parsing; and unnamed "AI providers" for classification and extraction, given as Google Gemini and OpenAI. Section 6 then states that data may be processed outside the EEA under adequacy decisions or standard contractual clauses.

Both statements can hold under GDPR, since standard contractual clauses are a lawful transfer mechanism, and the operator, the contracting entity and the register entry behind it are all genuinely German. But a buyer who reads "never leaves Europe" as strict data residency, and many public-sector and regulated buyers must, is reading a marketing sentence rather than a contract. The data processing agreement is offered on request and is where that question gets settled in writing. Ask for the current subprocessor list and the processing regions along with it.

The related badge is "NIS2 Ready", which appears on every page of the site. It is a self-declaration rather than an audit result. The site offers no SOC 2 report, ISO 27001 certificate or other third-party attestation.

Several claims rest on the vendor's own word

OneStop Pro Software Solutions GmbH, a construction asset-management vendor two kilometres away in Passau, is the only customer named anywhere. Its CEO Dominik Märkl supplies the homepage quote about saving up to 90% of the time spent on manual document work, and the reference sits under a "Trusted by" heading followed by "+ other pilot partners", the vendor's own word for the stage these deployments are at. The 60,000 documents and the 90% both come from that project as Klaaro tells it, in a success-story video Klaaro produced; the customer has published nothing of its own.

A search of G2, Capterra and the other software directories in September 2026 returned no reviews of Klaaro, which is what three months on the market usually looks like and which leaves the usual cross-checks unavailable. Headcount is seven and the company states it has taken no outside investment, so the counterparty risk on a multi-year contract differs from that of a funded competitor such as Rossum or an established German incumbent such as Konfuzio or natif.ai. The free trial makes it cheap to answer the accuracy question on real documents, and that is where an evaluation of this vendor should start.

Technical specifications

Resources

• Klaaro website
• Documentation and free schema catalogue
• MCP server setup and integrations
• Pricing
• Product walkthrough video and founder introduction
• OneStop Pro success story and the Klaaro YouTube channel
• Privacy policy and legal notice
• npm package, PyPI package and n8n node
• synsugar GmbH, the operating company

Company information

Klaaro by synsugar GmbH
Innstr. 69b
94032 Passau, Germany
HRB 11793 (Amtsgericht Passau), share capital €25,000
Managing directors: Sarah Stemmler and Sebastian Henneberg
VAT ID: DE353253776
support@klaaro.ai, +49 851 86674999
klaaro.ai