Getting paid / Remittance slip
A tear-off remittance slip at the foot of an invoice
A detachable panel at the bottom of the page carrying the reference, the amount and the payee, meant to be torn off and returned with a payment.
Why this block is harder than it looks
A remittance slip has to be at the bottom of a specific page, has to be a fixed distance from the paper edge so it can be torn or cut consistently, and has to repeat the identifying information from a document it is about to be separated from. That last point is the one people miss: once it is detached it is a standalone object, so anything it omits is lost. The positioning is also awkward, because bottom of the page and bottom of the content are different things, and only one of them is what you want.
The decisions that make it work
Reasons rather than a description of the code. Each of these is a choice that has a wrong answer, and the wrong answer is usually the default.
- Position it from the bottom edge of the page in millimetres, on the last page only, rather than letting it follow the content. Content ends wherever it ends.
- Draw the tear line as a dashed rule with a scissors glyph or a short instruction, so nobody wonders whether it is decoration.
- Repeat every field the recipient needs after separation: payee, reference, amount, due date, and your own account details. It has to work with nothing else in the room.
- Keep it clear of the bottom margin your printer can actually reach. Most laser printers cannot print within about 5mm of the edge and will clip a rule that goes closer.
- Leave a writing area if the payer is expected to fill anything in, sized for handwriting rather than for type, which means at least 8mm per line.
- If the document may run to several pages, make sure the slip appears once. A remittance slip on every page produces duplicate payments.
The fragment
Markup and the CSS it needs, and nothing else. It expects a document that already has a page rule and a base stylesheet, so paste it into one rather than opening it on its own.
<section class="remit">
<div class="tear">Detach and return with your payment</div>
<dl>
<dt>Pay to</dt><dd>Wynne and Hall Ltd</dd>
<dt>Reference</dt><dd>WH-2026-0418</dd>
<dt>Amount due</dt><dd>5,016.00 EUR</dd>
<dt>By</dt><dd>13 April 2026</dd>
</dl>
</section>
<style>
.remit {
position: absolute;
left: 0; right: 0;
bottom: 12mm; /* from the paper edge, not from the content */
padding: 6mm 20mm 0;
}
.remit .tear {
border-top: 0.75pt dashed #999;
padding-top: 3pt;
margin-bottom: 6pt;
font-size: 7.5pt;
letter-spacing: 0.08em;
text-transform: uppercase;
color: #777;
}
.remit dl {
display: grid;
grid-template-columns: auto 1fr auto 1fr;
column-gap: 8pt; row-gap: 3pt;
margin: 0; font-size: 9pt;
}
.remit dt { color: #555; white-space: nowrap; }
.remit dd { margin: 0; font-weight: 600; }
</style>What breaks when it is built the obvious way
Letting the slip sit in the normal flow so it lands wherever the content ended. On a short invoice it appears halfway up the page and reads as another section, and on a long one it lands at the top of a second page on its own. It has to be positioned from the page.
How to prove it survived pagination
Render a one-line invoice and a ninety-line invoice. The slip should be in the same place on the paper in both, appear exactly once, and sit far enough from the bottom edge that a real printer prints the tear rule rather than clipping it.
Where it sits in a finished document
This page is one block. The document it belongs to has a page rule, a base stylesheet, a header and everything else around it, and repeating all of that here would make thirty pages that say the same thing. The invoice template is a complete file with this block already in it, so take that and change the fragment rather than assembling one from parts. The property doing most of the work here is covered on its own page, with the support caveats that belong there rather than here.
Frequently asked
Will this fragment work on its own?
Not as a whole document. It has no page rule, no margins and no base type, because those belong to the document rather than to the block, and duplicating them in every fragment would mean thirty copies to keep in step. Paste it into a template that already has them.
Why does it look right in a browser and wrong in the PDF?
Because a browser window is one continuous surface and a document is a stack of fixed rectangles. Nothing in a scrolling view exercises a page boundary, so every break rule in the fragment is inert until the content is paginated. Render the real thing with enough content to cross two or three boundaries, then look.
Do I need a special option on the render request for this?
No. Everything on this page is CSS and markup, which is your side of the boundary. What the render has to give you is a real page size with real margins, and after that the layout is decided by the stylesheet.
Other parts of a document
The blocks that sit next to this one, and one from the next group along so you are not sealed inside a single kind of problem.
An instalment schedule where the amounts visibly add to the total
A table of dated payments making up a total, used on staged contracts, payment plans and deposit-plus-balance arrangements.
Showing a deposit already paid and the balance still due
A block that subtracts what has already been received from the invoice total and states the remaining amount, which is the only figure the payer should act on.
A direct debit mandate laid out to be completed by hand
A form section collecting account details, a signature and a date, to be filled in on paper and returned.
Per-page initials boxes and date fields sized for handwriting
Small boxes for a signatory to initial each page or enter a date by hand, used where every page has to be shown to have been seen.
Invoice, as a complete file
The whole document with this block already in place, ready to copy and change.
position: fixed in paged output
The property carrying the weight here, with its real support status.
Every part of a document
The full list, grouped by the kind of problem the block poses.
Paste the fragment into the playground inside a page rule and see what it does at a real page size. That is the only way any of this gets confirmed.