Invoice rendering is allowed to be convenient. Invoice finalization is not.
Klevar Docs can render invoices, pro-forma invoices, credit notes, receipts, statements, and supporting documents through a common document layer. Sending an invoice is a stricter path. It may need EN16931 Factur-X, XRechnung, PDF/A-3b, PAdES signing, storage, hash-chain insertion, and event fanout.
The rule is fail closed. If the compliance artifact cannot be produced, the system must not create a clean-looking substitute.
The Factur-X branch shows the posture:
const validation = await validateFacturXXml(xml);
if (!validation.valid) {
throw new FacturXValidationRejectError(validation.errors);
}
const pdfa = await convertToPdfA({
pdfBuffer: embeddedPdf,
documentId,
entityId,
});
if (!pdfa.valid) {
throw new PdfARequiredRejectError(pdfa.errors);
}
That is the right kind of rude. A bad XML payload should stop the send. A PDF/A failure should stop the send. A signing failure should stop the send. Silent fallback is worse than an error because it produces evidence that looks official.
One Phase N bug made this concrete. Credit-note payment terms had been inherited into the domain flow, but the Factur-X builder did not emit the field all the way into the sidecar DTO. The visible symptom was a BR-CO-25 validation failure. The fix was not to weaken validation. The fix was to propagate the missing field through the builder and sidecar path.
The builder also has to stay entity-driven. Seller registration details come from the entity snapshot. That matters because FZE, LLC, and Nigerian Ltd do not share one registration regime. A compliance XML file is not just totals and line items. It carries legal identity.
XRechnung adds another branch. German public-sector routing cannot be treated like a Factur-X attachment with a different filename. The send path chooses the correct profile, builds the XML, validates what can be validated locally, uploads the artifact, and records the event path separately.
The sidecar split is pragmatic. Node runs the Fastify API and orchestration. Java handles mustangproject and EU DSS inside a signing sidecar over Unix sockets. The container boundary keeps the compliance toolchain pinned without forcing the main service to pretend those libraries belong in the Node process.
The key product behavior is blunt: a draft can exist without compliance artifacts. An issued invoice cannot fake them.
That posture is what separates a document renderer from a document system. A renderer makes output. A system decides when output is not allowed to exist.