Invoices

Render line items and totals as a paged document. If your invoice format needs embedded XML, attach it and set the PDF/A and XMP options the format requires.

A plain invoiceCopy Anchor Link

Here, invoice is your invoice data and InvoiceDocument is your JSX template. Line items flow across pages, and the footer carries the page counter. measure() returns the footer's height, so you can reserve enough bottom margin:

import { googleFonts } from "@takumi-rs/helpers";
import { measure, render } from "takumi-pdf";
import { PageNumber, TotalPages } from "takumi-pdf/primitives";

const footer = (
  <div tw="flex w-full justify-between px-12 text-[10px] text-[#6b7280]">
    <span>Invoice {invoice.number}</span>
    <span tw="flex">
      Page <PageNumber /> of <TotalPages />
    </span>
  </div>
);

const fonts = await googleFonts(["Inter"]);
const { height } = await measure(footer, { size: "a4", fonts });

const pdf = await render(<InvoiceDocument data={invoice} />, {
  size: "a4",
  margin: { top: 48, bottom: height + 32, left: 48, right: 48 },
  footer,
  fonts,
});

For complete templates, see the invoice and receipt example.

Use break-inside: avoid, or break-inside-avoid in Tailwind, to keep a line item on one page:

import "takumi-pdf";

<div tw="flex break-inside-avoid gap-3 pt-3 text-xs">
  <span tw="flex-1">{item.description}</span>
  <span tw="w-[100px] text-right">{item.amount}</span>
</div>;

Apply the same style to the totals block.

Electronic invoicesCopy Anchor Link

Factur-X and ZUGFeRD combine a readable PDF invoice with structured XML. Map what your profile requires to these options:

Each attachment's modificationDate falls back to metadata.creationDate, so one document date covers both. This example also validates against PDF/UA-1:

import { render } from "takumi-pdf";

const pdf = await render(invoice, {
  lang: "en",
  pdfa: "3b",
  tagged: "ua1",
  metadata: {
    title: "Invoice INV-2026-0042",
    creationDate: "2026-08-06",
    xmp: [facturXmp],
  },
  attachments: [
    {
      name: "factur-x.xml",
      data: xml,
      mimeType: "text/xml",
      description: "Factur-X 1.0 MINIMUM invoice data",
      relationship: "data",
    },
  ],
});

The renderer checks PDF conformance while writing. It does not check the invoice XML, tax rules, or whether a receiving system accepts the file.

Takumi does not build the invoice XML. Use a library for your profile, or write the elements the profile lists. The e-invoice example writes a MINIMUM profile by hand, along with the facturXmp schema used above.

Validating the resultCopy Anchor Link

Two validators cover the two halves. Both need Java.

veraPDF checks the container:

verapdf --flavour 3b --format text invoice.pdf
verapdf --flavour ua1 --format text invoice.pdf

Mustang checks the Factur-X half, both the XML and the packaging:

java -jar Mustang-CLI.jar --action validate --source invoice.pdf

Mustang finds the profile through the fx: XMP block. Takumi writes each value together with the schema description PDF/A requires, so the two cannot disagree. It does not check the values, so a wrong profile name shows up in Mustang, not at render time.

Accessible invoicesCopy Anchor Link

For PDF/UA-1 output, set tagged: "ua1", lang, and metadata.title. Then review the reading order and table structure yourself. See PDF/A and PDF/UA.

Reproducible bytesCopy Anchor Link

Same content, resources, renderer version, and metadata.creationDate produce the same bytes. A new date changes the file even when the invoice looks the same.