Invoices

An invoice needs line items that flow across pages, totals that stay in one piece, and a footer with a page counter. Some formats also need embedded XML. Takumi renders the invoice as a paged document, and for those formats you attach the XML 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. Headers & footers covers the footer in full.

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. Pagination lists every break property.

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. The table maps what your profile requires to the option that provides it:

Each attachment's modificationDate falls back to metadata.creationDate, so one document date covers both. See Attachments for every attachment field. 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",
    },
  ],
});

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, and 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 & PDF/UA.

Reproducible bytesCopy Anchor Link

The 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.