Capabilities
Ordered by force, not alphabetically — from five-layer validation to a data kit with your own name on it. Every capability comes with the situation it saves. At the bottom: what the others offer, with sources.
XML schema, EN 16931, the format (XRechnung, ZUGFeRD / Factur-X, Peppol BIS 3), the country CIUS and the PDF/A-3 container. 1,784 checks on every run, 1,749 of them from the official rulesets.
Use caseAn invoice arrives by mail. Two seconds later you know whether you may book it or must reject it — with the rule number and the field, not a red cross.
Cross-checked against the official KoSIT validator 1.6.2 and the EU test bed: 352 samples, 0 disagreements. Proven in our CI and re-proven with every ruleset bump.
Use caseThe supplier says "my file is valid". You show them the verdict the authority will reach — three weeks before it reaches it.
Errors, warnings and advisories are reported apart, including "would be an error under the current version". Every result names the ruleset it was produced under and can be re-run against a different one.
Use caseThe invoice was valid in January and is not any more. The time machine shows which ruleset version changed that — the basis for the conversation with the supplier.
Not "is this invoice valid" but "will this recipient accept it": pick the target profile, check against its rules. Including the Leitweg-ID with its check digit, which the standard rulesets do not verify at all.
Use caseFirst invoice to a public authority. The preflight tells you before you send whether it will pass — instead of the rejection letter three weeks later.
Every result carries an acceptance-risk tier rather than just valid/invalid. And the amount of input VAT hanging on the document is stated as a figure beside it.
Use caseInstead of "three warnings", accounting reads: €4,560 of input VAT depends on this invoice. That is what decides whether someone picks up the phone.
A declarative policy pack on top: required fields, allowed values, your own limits — checked in the same output as the official rules, without touching the rulesets.
Use caseGroup policy requires a purchase-order number on every inbound invoice. Without one the invoice is valid under EN 16931 — and still a finding at your desk.
An e-invoice may carry files. We check what no official ruleset checks: deceptive file names, names carrying a path, references that are neither web nor mail addresses. External references are never fetched.
Use caseThe invoice carries a "timesheet.pdf" that is in truth something else. That is in the result before anyone clicks it.
A ZUGFeRD PDF has two faces: the printed page and the XML inside it. We reconcile the expensive anchors — grand total (BT-112), payment IBAN (BT-84), invoice number (BT-1). A pure XML validator never sees that mismatch.
Use caseThe page shows the right IBAN, the XML a stranger’s. Booking and payment follow the XML. This is where it surfaces, before the money is gone.
The plain reconciliation can be gamed: white ink, font size 0.0001, full transparency, positioned off the page, clipped away, painted over, glyphs of no width, the invisible text-rendering mode. Eight mechanisms — all detected. Concealment has no innocent explanation, which makes it the strongest fraud signal in the whole feature.
Use caseThe honest total is written in white on white so the validator finds it and stays quiet. The page your bookkeeper opens says something else. We report the hiding place, not the agreement.
An embedded font can declare that the glyph drawn is a different character from the one extracted. This is the sharpest attack: a clean verdict on a document whose visible total is wrong. We decode honestly — what is drawn is what counts.
Use caseThe page shows €9,999.00, the XML says €999.00, and the font makes the check read €999.00. Exactly that case is pinned down as a committed fixture.
A PDF can carry two correctly-named ZUGFeRD payloads with different totals and different IBANs; which one counts is decided by the receiving system. That is reported. Plus the full PDF/A-3 container validation. 22 attack fixtures live in the repository, 4 of them honest documents that must stay clean — if a defence stops working, the build fails.
Use caseTwo systems read the same file and book different amounts. Without this finding nobody notices until the dunning letter arrives.
What can be fixed safely is fixed: structural repairs and value-preserving normalisations — whitespace, escaping, date format, element order. A third ring proposes and waits for your confirmation. It never touches amounts, tax rates or the IBAN. With a before/after diff.
Use caseThe ERP exports 40 invoices with the elements in the wrong order. One run, 40 valid files, every original left untouched beside them.
Correct any field straight in the XML, with line numbers and syntax highlighting, re-validated instantly — then download the corrected file or the repaired ZUGFeRD PDF.
Use caseA typo in the tax number is blocking payment. Twenty seconds instead of a support ticket with the software vendor.
Click a finding and the field it means lights up in the readable invoice view — driven by the BT/BG identifiers the rule already cites. No XPath reading.
Use caseThe colleague in accounting should fix the error, not IT. She can see which box is meant.
Every validation rule explained and linked straight from each result, with the UBL and CII path side by side. When the totals do not add up we name the amount, what the other figures make, and the difference — in German, English and French.
Use caseInstead of "BR-DE-15 violated" you read which field is missing, why it is mandatory and what belongs in it.
"My invoice was rejected — who is right?" Paste in the file and the reason given, and get back whether the invoice really breaks a rule or the receiving system is stricter than the standard.
Use caseThe customer rejects it, you are sure the file is fine. Instead of arguing by email there is a rule reference on the table.
A guided flow or the full form, both showing validity as you type. Small-business exemption, payment terms, BIC, order reference, free texts, attachments — output as XRechnung (UBL or CII), a ZUGFeRD PDF or Peppol BIS 3.
Use caseThe first customer demands an e-invoice from now on. No software to buy, no training: fill in the form, download a valid file.
A sent invoice is not edited, it is cancelled. One click opens it as a credit note (381) or correction invoice (384), carries over every detail and records the reference to the original (BT-25).
Use caseWrong amount, invoice already out. The clean route takes one click instead of a question to the tax advisor.
Beyond XRechnung and Peppol, the national flavours too: the Netherlands (NLCIUS), Romania (CIUS-RO / e-Factura), Croatia (HR-CIUS), Portugal (CIUS-PT), plus France and Belgium with the right presets and identifiers — SIREN/SIRET are checked against their check digit.
Use caseThe first French customer. No second piece of software, no second vendor: the same interface, the right ruleset.
Saved invoices and templates, customer records, monthly/quarterly/yearly recurring invoices that advance the number and the period. On the PDF: your logo, accent colour, a payment QR code and a note.
Use caseTwelve identical rent invoices a year. Set up once, confirm eleven times — and the document looks like it came from your company, not from a tool.
CSV, XLSX or ODS as the source: columns are pointed at fields rather than having to be named after them, a dry run lists every invoice with its number and amount before anything exists — and every number issued is recorded locally so it cannot be issued twice.
Use caseOn the first of the month, 300 invoices out of the time-tracking export. First the dry run, then 300 valid files.
UBL ↔ CII ↔ ZUGFeRD PDF, locally, with a fresh validation after every conversion. And a validated e-invoice can be embedded into a PDF of your own.
Use caseThe recipient only accepts CII, your software only writes UBL. Two clicks instead of an ERP project — and the file was never on someone else’s server.
A ZUGFeRD PDF is treated as what it is: the printed page and the embedded XML together, readable side by side in summary or full detail — instead of pulling out the XML and forgetting the page.
Use caseThe inbound invoice has to be validated and read by a person at the same time. Both in one view, without a second program.
A positioned text layer rather than guesswork, per-sender templates, and a confidence with provenance on every field. The least certain fields come first in the review. A result is never presented as certain when it is not.
Use caseThe supplier keeps sending PDFs. Instead of retyping you read it in, confirm the three uncertain fields and have a structured invoice.
Scanned invoices with no text layer are deskewed, binarised and recognised in the browser — the engine is only loaded when it is needed. Nothing goes to a recognition service.
Use caseThe scanned document from the 2019 folder has to get into the system. It does not leave the building on the way.
Delivery note, spreadsheet, contract, mail: the reader takes sixteen formats, decides by the bytes and never by the file extension, keeps the kind of every cell and works to a fixed budget — a stranger’s file gets no unlimited compute.
Use caseThe invoice comes with a timesheet as a spreadsheet. It is read and displayed without opening Office and without macro risk.
An invoice can be EN 16931-valid and still incomplete for VAT purposes. A separate content check walks the mandatory particulars — advisory, never a rejection.
Use caseThe invoice is technically valid but the reverse-charge notice is missing. That costs the input-VAT deduction later, not the acceptance today.
VAT identification numbers from fourteen member states are checked against their check digit. Plus five risk patterns, among them the fictitious intra-Community supply.
Use caseThe new supplier from another EU country invoices without tax. Is the number even formally sound? The answer comes before the payment.
Place of supply, exemption, rate and the person liable are worked out deterministically — with the provision the decision follows from. Where the data is not enough, it abstains explicitly instead of guessing.
Use caseConsulting work for a customer in Belgium. Who owes the tax? The answer is there, with the citation beside it.
Whole folders on web, desktop and terminal, key figures rather than a file list, a report as PDF and CSV — on the practice’s letterhead if you want. Repair and convert run in batch the same way.
Use case800 inbound documents for one client run overnight. In the morning you have the twelve to reject.
Not "is this file valid" but "what is actually in here": what is an e-invoice at all, what is an unstructured PDF, who is still sending the wrong thing — classed the way the official guidance classes it.
Use caseNew client, one folder with 2,000 documents. After one run you know which suppliers have to be spoken to.
One appended line per checked document, never rewritten — the proof that checking happened, when, and against what. Readable in the app, not only as a file.
Use caseThe tax audit asks how inbound invoices were controlled. The journal is the answer, not a description of the procedure.
A draft of the e-invoicing chapter of the GoBD process documentation, on letterhead. Plus a sealed set in which each entry is chained to the one before: change a document, a field or the order and the root changes — a single value you write down. Delivered as a per-client bundle.
Use caseThe practice has to document and to evidence. Both come out of the same data, in an evening rather than a project.
Every other command judges a document; this one judges the partner records behind it: who has no electronic address, whose VAT id is invalid, who is filed twice. From an ERP export, from the invoices you already have — or from both, which also shows where they disagree.
Use caseKnow before the switchover which 40 of your 900 vendors will make invoices fail. Afterwards it costs more.
260 valid and 135 deliberately defective e-invoices in fourteen groups — every VAT category, every document type, eight currencies, six countries, attachments, allowances, PDF scenarios. The manifest names the kit version, a content hash, the generation date and every pinned ruleset: nobody can be told they were tested against a newer kit than they were.
Use caseThe ERP vendor wants to know whether their inbound validation is any good. They run 395 files through it and compare against the shipped verdict — file by file.
For every generated defective sample the corrected original ships alongside — exactly the state before the injected defect. A diff between the two shows precisely that defect and nothing else.
Use caseThe test fails and nobody knows why. The diff against the golden sample answers that in one line.
The wizard puts your parties, line items, bank details and free texts into the kit and builds it in the browser — 395 samples rendered, validated and zipped, with no upload. It shows in advance how many samples each entry reaches (measured, not declared) and stops the build if a verdict would move because of it. Optionally with a watermark on every page. The same run exists as a command, so a kit built in a tab and one built in CI are the same artefact.
Use caseThe software vendor sends customers test invoices carrying the customer’s real company details — instead of "Example Ltd", which looks like nothing an import will ever meet.
A dated A4 report on what a solution was tested against and what it found: detected, missed, wrongly accepted, false alarm, no verdict. Declining to answer does not score better. With the kit version, content hash and every ruleset version — identical input, identical report. Optionally with a partner’s name and logo.
Use caseThe practice puts in front of the client, in black and white, what their software was tested against — on its own letterhead, with a date.
Validate, fix, generate, convert, extract, take stock, journal, seal, build a kit, write a report — all with no account and no network. Exit code 0 or 1, output as JSON if you want it.
Use caseThe invoice is produced in the build. An invalid document turns the pipeline red before anyone receives it.
Eleven tools — validate, report, extract XML, fix, repair plan, tax risk, convert, read from a PDF, generate, read a document, explain a rule. Local, no API key, findings as JSON with a repair plan.
Use caseThe agent writes the invoice; Beleggo refuses to pass it when it is invalid. A probabilistic model gets a deterministic guardrail.
Another system writes files into a folder and the verdicts come back beside them. Or it asks over HTTP — at an address only this machine can reach.
Use caseThe old ERP cannot embed a library but it can write files. That is enough to integrate it.
A document-transfer package or a real posting batch for DATEV; the advisor and client numbers are asked for, never guessed, and the batch stays uncommitted. For Peppol, the finished envelope with its manifest — Beleggo is not an Access Point and transmits nothing.
Use caseThe checked documents have to reach the practice software and the service provider. Two commands, no clipboard.
Validation runs in your browser or on your machine. There is no server that accepts documents and no account they would sit under. Open the network tab or pull the cable — it keeps working.
Use caseA tax practice validates client documents with no data-processing agreement and no professional-secrecy question: the documents never leave the building, because there is no third party.
What stays in the browser stays encrypted: a key held on the device, encrypted records and a chain that makes tampering visible. Backup with a passphrase. Stated plainly: the key is on the same device as the data — against a lost laptop, full-disk encryption is what helps, not us.
Use caseDrafts and validation results sit on the practice machine. They are not readable in the clear, and a later change shows up.
A real invoice becomes a sample that can be handed on safely: identities are replaced by same-shape invented ones, so validity and rule behaviour survive. Dates all move by the same offset, amounts are masked.
Use caseThe problematic invoice has to reach the software vendor — without giving away the customer name, the bank details and the amounts.
A desktop app for Windows, macOS and Linux, and an installable PWA in the browser. No Java runtime, no Docker, nothing anyone has to run and keep patched.
Use caseAt a client’s office with no Wi-Fi, on a plane, inside an air-gapped public network: validation runs anyway, with the same verdict.
A bug report is written as a bundle on your own disk: the steps before it, the environment, no screen captures and no invoice data. Whoever receives it can replay the sequence.
Use caseSomething goes wrong on a client invoice. The report describes the sequence, not the client.
More detailSearch the error libraryDownload test invoicesGet the desktop app
Under your brand
Beleggo relabels onto the practice completely — the app, the reports, the test data. What comes out of that does not only sit on your own desk: it is an offer to your clients that a practice without a server of its own could not otherwise make.
An app with the practice’s name on it
Name, subtitle, header line, logo, accent colour and page background come from configuration, not from a support ticket. The standing advisory above each view is the practice’s own wording too — per view and per language.
Two shapes, the same engine
The full app — validate, readable invoice, findings list, ruleset timeline, ruleset picker, exports, create. Or the minimal one: drop a file in, VALID or INVALID, nothing else. The two are built separately and can ship side by side.
No infrastructure
A folder of files on the web space you already have, including under a sub-path of the practice website. No server, no database, no Java, nothing anyone has to run, back up and keep patched.
Reports on the letterhead
The validation report as PDF and CSV, the readiness report, the process-documentation draft and the per-client bundle all carry the practice’s logo and accent colour. The letterhead is configuration and lives outside the program — it is maintained, not recompiled.
Test data with the practice’s name
The data kit can be generated with the practice’s details — or a client’s. The readiness report and the comparison page carry the partner’s name, address and logo.
"Check your invoice on our website."
The client drops their file into the practice’s app and has a verdict immediately — no account, no upload, and without the practice ever seeing the document. The file stays on the client’s machine. That is precisely the offer a competitor with a server upload cannot make.
The client creates a valid invoice themselves
For everyone who has no ERP and is not going to buy one: fill in the form, download a valid XRechnung or ZUGFeRD PDF, with validity shown as they type. The client saves the software purchase, the practice saves the phone call.
A dated record per client
What a client’s software checked and what it found: detected, missed, wrongly accepted, false alarm, no verdict. On the practice’s letterhead, with the date, kit version, content hash and every ruleset version — identical input, identical report.
Test invoices that look like their own
Instead of "Example Ltd", a kit carrying the client’s real company details. They test their own inbound processing against documents that resemble their actual traffic — not against examples any import can tell are examples.
The whole document folder, gone through once
A stock-take and a batch run over a client’s complete inbound: what is an e-invoice at all, what is an unstructured PDF, which suppliers are still sending the wrong thing, which documents have to be rejected. A service with a result that can be billed.
The process documentation they need anyway
The e-invoicing chapter as a draft on the practice’s letterhead, plus the validation journal and the sealed set that evidence the checking happened. Two billable deliverables out of the same data, in an evening rather than a project.
And the question nobody else answers cleanly
No data-processing agreement, no professional-secrecy question — because there is no third party for anything to be disclosed to. A client’s documents reach nobody: not us, and not even the practice when the client checks them.
Relabelling and distribution need an OEM licence; editing and previewing do not. The shape is discussed rather than picked from a cart — and Beleggo is not an Access Point and transmits nothing, and software cannot be GoBD-certified.
Head to head
Five named vendors, only statements published on their own pages, every line with its source. On the left, what they publish. On the right, what Beleggo offers.
Other vendors
Beleggo
Nothing uploaded — local in browser/desktop
Other vendors
Beleggo
Unlimited (web + desktop)
The full table, with date and source per cell →
All third-party figures come from the vendors' own public pages (see the date column) and may change. No judgement, just facts.
A figure out of date or wrong? Tell us — we correct it promptly.
No account, no upload, no daily cap. If anything on this page is wrong, tell us — we correct it.
Get started