No monthly fee, no start fee, no seat. You are charged for a document that was parsed, and for nothing else.
Answer: valid or not, against the published rule set, with the rule id, the severity and the location of every failure.
A canonical invoice JSON in, XML out, in the profile you asked for. The output is validated before it is returned, and invalid output is never returned.
The same input, returned as a PDF a human can read with the machine-readable invoice embedded inside it.
The other direction: an XML or a Factur-X PDF in, the canonical JSON out, for the receiving side.
Per document, metered, no monthly fee and no start fee. These are the intended list prices for the four operations. No prices are attached to the endpoint yet, so nothing is being charged to anyone today. Bulk use through an accounting practice is invoiced by NeuraScale in euro instead of metered here.
You do not pick a profile. The validator reads the customizationId out of the document, matches it to a scenario, and names the scenario it used in the answer.
A number out of ten tells a developer nothing about what to change. Every failure comes back with the identifier of the rule that produced it, so it can be looked up in the published rule set, and the rule set versions come back with it so an answer can be reproduced later.
{
"valid": false,
"profile": "EN16931 XRechnung (UBL Invoice)",
"syntax": "ubl",
"source": "xml",
"durationMs": 164,
"errors": [
{
"ruleId": "BR-CO-16",
"severity": "error",
"message": "[BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
"xpath": "/Q{urn:oasis:names:...:Invoice-2}Invoice[1]/...LegalMonetaryTotal[1]",
"step": "val-sch.1"
}
],
"warnings": [],
"notices": [],
"validatorVersions": {
"kositValidator": "1.6.3",
"xrechnungConfiguration": "xrechnung-3.0.2 release 2026-08-31",
"mustang": "2.26.0"
}
}A real answer, with the xpath shortened to fit. Those version strings are the ones pinned in the running build: KoSIT validator 1.6.3, the XRechnung 3.0.2 configuration released 2026-08-31, Mustang 2.26.0. Each artifact is checked against its sha256 at build time, so a silently replaced release asset fails the build rather than quietly changing a verdict. One thing worth knowing before you integrate: valid is the validator's own verdict, not one we compute, and a handful of rules are classified as warnings and still make the report reject the document. When that happens you get valid false with an empty errors array and the reason in warnings.
Every row below was measured on 6 September 2026 against the running validator, and where a row is a range that range is the whole spread rather than the best of it. They are one day's numbers on one connection, not a service level, and they are here because a docs page with no numbers on it is asking you to take its word.
The box below is wired to the real route, and the route is wired to the real validator. What is missing is one thing: a demo access token, which only the account owner can issue. Until it exists the route says so and the box prints that answer instead of a fake result. The day the token is set, the same box starts returning real validation output and nothing else on this page changes. Capped at 20 documents a day per address.
A practice does not want an API. It wants its clients moved off spreadsheets and templates without changing the tool anyone works in, one client at a time, at a price it can quote. That is a different page and it is open today.
E-invoicing onboarding for accounting practicesTechnical validation against the published rule sets. Not tax or legal advice. Transmission to a tax authority or to a certified platform is outside this service.
France is the case where that matters most, so it is worth saying before you build against this rather than after. Only a registered platform, a plateforme de dematerialisation partenaire, may transmit an invoice in France. NeuraScale is not one and will not become one. You need a platform account of your own, contracted directly with that provider. This endpoint produces and checks the document; getting it to the other side is the platform's job.