Documents you can
rebuild

Typst is a typesetting system: you write text with a little markup into a file, and Typst turns it into a PDF.

Compared with a word processor, everything lives in a readable text file that can be versioned, compared and compiled automatically – the same source gives the same PDF. Compared with LaTeX, the syntax is shorter, errors name file, line and column, and templates are functions in a real programming language.

Headings start with =, bold text sits between asterisks (*bold*), functions start with #: #table(…), #image(…), #bibliography(…). Formulas sit between dollar signs. Data comes into the document with json(…), csv(…) or yaml(…).

This guide uses typstgen: a small tool that compiles .typ files to PDF with an embedded Typst engine – as a command line, a Rust library, WebAssembly and an MCP server for AI agents. No typst installation is needed.

A document comes from data and a template. What happens next decides whether it can still be trusted in eight years.

check reports errors with file, line and column, preview shows a page as an image, compile writes the PDF – as PDF/A if needed, and for invoices with embedded ZUGFeRD XML.

A manifest records what each PDF was built from. verify rebuilds it later and compares byte for byte. The three checking steps are available to an AI agent over MCP as well.

For most documents, typstgen and a template are enough. Reports generated from program code call for a library.

typstgen compiles any .typ file. It finds templates through template_paths in typstgen.toml and loads Typst packages such as @preview/… from the same folders as the Typst CLI – or not at all, if configured that way.

business-templates provides 19 business documents as a Typst package: invoice, offer, credit note, reminder, delivery note, order confirmation, letter, credentials, concept, contract, documentation, proposal, minutes, SLA, specification, task list, time sheet and handout. Accounting documents take JSON data, the others named parameters and the text as content. The layout is German (DIN 5008).

RenderReport is a Rust library for data-driven reports built from components (scores, findings, tables, charts), with Typst as the embedded engine; every PDF is PDF/UA-1.

The data changes. The template stays. The PDF is just the result.

A folder per document type and year works well, with the document number as file name: invoices/2026/RE-2026-001.json holds the data, RE-2026-001.typ next to it is a thin wrapper that brings template and data together. Master data such as company.json lives once, centrally.

Data, wrapper and manifest are small text files and belong in version control; the history shows who changed what and when. PDFs belong in the archive storage, not in Git – the manifest ties both together.

If you keep a knowledge base for AI systems, store a compact summary of each case there and point to the source with document_id and typst_source. The system reads the entry, the customer gets the PDF; PDFs stay out of the search index.

Since 2025, businesses in Germany must be able to receive e-invoices; they must issue them from 2028 at the latest.

A ZUGFeRD invoice is a PDF/A-3 that carries the same data a second time as XML (UN/CEFACT CII, profile EN 16931). For VAT, the XML is the leading part.

typstgen builds the XML from the same JSON data the invoice template renders. It recomputes lines, VAT per category and totals first; if the JSON states different numbers, the build fails – otherwise the PDF would show something else than the XML. Covered: standard and reduced rate, 0 %, exempt with a reason, and reverse charge.

PDF/A keeps a file readable. That it is unchanged has to be shown separately.

typstgen compile --manifest archive.json records for each PDF which source, which options and which files it was built from – with SHA-256 of the PDF, templates, data, images, package files and fonts.

typstgen verify later checks three things: the stored PDF is unchanged, a rebuild reads the same files, and it produces the same bytes. That needs a fixed timestamp and pinned fonts and packages for every document.

Locally the check is binding; in CI it is the proof at release time.

typstgen verify runs before every push – as a script or a pre-push hook. CI has no PDFs, since they live in the archive; there, verify --rebuild-only checks only that every source yields the recorded bytes.

For a rebuild on another machine to match, fonts and packages belong in the repository: use_system_fonts = false, font_paths = ["fonts"], package_path with download_packages = false. A template that asks for a system font such as Helvetica looks different on Linux otherwise.

An AI agent writes Typst quickly – and makes mistakes. Over MCP it can find and fix them itself.

typstgen mcp is a Model Context Protocol server on stdin/stdout with four tools: check (errors with line and column, writes nothing), preview (a page as an image), compile (PDF, optionally PDF/A or ZUGFeRD) and list_templates. All paths are confined to the workspace.

A division of labour works well: the agent writes data (JSON) and text, the template takes care of the layout, and a person reviews the result before it goes out. For e-invoices the data comes from bookkeeping, not from the language model.