What is the difference between Mustangproject and Factur-X Engine?

Mustangproject is an open-source Java library that must be embedded in your application. Factur-X Engine is a language-agnostic REST API deployed as a Docker container. Mustangproject requires a JVM and Java expertise; Factur-X Engine can be called from any language (Python, Node.js, PHP, Go) via HTTP. Factur-X Engine includes full Schematron + PDF/A-3b validation via VeraPDF; Mustangproject offers lighter validation.

When should I choose Mustangproject over Factur-X Engine?

Choose Mustangproject if your stack is already Java-based, you want an embeddable library with no network overhead, or you need offline generation without Docker. Mustangproject is MIT-licensed and well-maintained for pure Java environments.

When should I choose Factur-X Engine over Mustangproject?

Choose Factur-X Engine if you work in Python, Node.js, PHP, or any non-Java stack; if you need polyglot support across multiple services; if you want stricter EN 16931 Schematron validation with VeraPDF PDF/A-3b compliance checks; or if you need a centralized validation microservice with zero JVM dependency in each service.

Does Factur-X Engine support ZUGFeRD like Mustangproject?

Yes. Factur-X Engine supports ZUGFeRD 2.4, Factur-X 1.0 (EN 16931), and XRechnung 3.0 — the same formats as Mustangproject. Both tools implement the CII (Cross Industry Invoice) XML standard required by EN 16931.

Guide / Comparison

Mustangproject vs Factur-X Engine

Both tools generate and validate EN 16931 e-invoices. They solve the same problem with fundamentally different architectures. This page helps you pick the right one for your stack.

Updated March 2026

Note: Mustangproject is a well-maintained open-source project with years of production use. This comparison is meant to highlight architectural differences, not to diminish their work. Choose the tool that fits your constraints.

At a Glance

	Mustangproject	Factur-X Engine
Type	Java library (.jar)	REST API middleware (Docker)
Language	Java (JVM required)	Python + isolated Java subprocesses
Integration	Import as Maven/Gradle dependency	HTTP calls from any language
Deployment	Embedded in your JVM app	Standalone Docker container
Validation	Built-in Java validators	Saxon-HE Schematron (same rules as Chorus Pro / KoSIT)
Formats	Factur-X, ZUGFeRD, XRechnung	Factur-X, ZUGFeRD, XRechnung, UBL, CII
Air-gapped	Depends on your setup	By design — zero outbound calls
License	Apache 2.0	MIT (Community) / Commercial (Pro)

When to Choose What

Choose Mustangproject if…

• Your backend is already Java (Spring, Quarkus, etc.)
• You want a library dependency, not a separate service
• You need in-process PDF generation with no network calls
• Your team has Java expertise for customization

Choose Factur-X Engine if…

• Your backend is Python, Node.js, PHP, Go, or any language
• You want language-agnostic integration via REST API
• You need an air-gapped, containerized solution
• You prefer delegating regulatory maintenance to a dedicated tool

Same Task, Different Approach

Generating a Factur-X PDF from business data:

Mustangproject (Java) Library call

// Requires JVM, Maven dependency, Java toolchain
ZUGFeRDExporterFromA3 exporter = new ZUGFeRDExporterFromA3()
    .setZUGFeRDVersion(2)
    .setProfile(Profiles.getByName("EN16931"))
    .load("invoice.pdf");
exporter.setTransaction(xmlContent);
exporter.export("facturx.pdf");

Factur-X Engine (Any language) REST API call

# Works from Python, Node.js, PHP, Go, curl…
curl -X POST "http://localhost:8000/v1/convert" \
  -F "pdf=@invoice.pdf" \
  -F "metadata=@invoice_data.json" \
  --output facturx.pdf

Performance & Memory Under Load

When embedded as a Java library, Mustangproject shares the JVM heap with your application. Saxon-HE (the XSLT engine for Schematron) allocates 50–150 MB per concurrent validation thread. Under sustained load — for example, validating 500 invoices per hour — this creates GC pressure in your primary application JVM.

Factur-X Engine runs Saxon-HE as an isolated subprocess. Each validation spawns a short-lived Java process, uses its memory, and exits — the OS reclaims all memory immediately. The FastAPI + Uvicorn layer adds less than 80 MB of baseline RAM. The full engine runs comfortably on a 512 MB VPS.

Metric	Mustangproject (embedded)	Factur-X Engine
Baseline RAM	JVM heap (256 MB min)	~80 MB (Python + Uvicorn)
Per-validation overhead	Shared heap, GC pressure	Subprocess, freed on exit
Min host RAM	512 MB + your app heap	512 MB total
Concurrency model	Java threads	Gunicorn workers (configurable)

Migrating from Mustangproject to Factur-X Engine

If you have an existing Mustangproject integration and want to move to a language-agnostic REST API, the migration is a two-step process:

1. Start the engine alongside your app — docker run -d -p 8000:8000 facturxengine/facturx-engine:latest. No changes to your app server required.
2. Replace the Mustangproject call with an HTTP POST to /v1/convert (generation) or /v1/validate (validation). Pass your PDF and JSON metadata as multipart form fields.
3. Remove the Maven/Gradle dependency and JVM heap configuration from your application. Your service is now stateless with respect to e-invoice processing.

Key Architectural Differences

Memory Management

Mustangproject runs inside your JVM — memory is shared with your application. Factur-X Engine runs Saxon-HE and VeraPDF as isolated subprocesses: each validation spawns a short-lived process, and memory is reclaimed by the OS immediately after completion. No JVM memory leaks under sustained load.

Validation Depth

The engine executes the official EN 16931 Schematron rules (the same ones used by Chorus Pro and KoSIT) via Saxon-HE. The Pro edition adds Smart Diagnostics that translate cryptic XPath errors into actionable messages like INVALID-IBAN or TOO-MANY-DECIMALS.

Polyglot Support

Mustangproject is a Java library — non-Java backends need JNI bridges, subprocess calls, or a wrapper service. Factur-X Engine is a REST API by design: any language that can make HTTP requests can generate and validate e-invoices.

Try Factur-X Engine

docker run -d -p 8000:8000 facturxengine/facturx-engine:latest

API Reference View Source