PDFPipe

Billing and receivables / A4

Remittance advice HTML template

Sent by the payer, not the seller: a note saying which invoices a payment covers and what was deducted from each.

When this document is the right one

You pay several invoices in one transfer. Without this document the recipient sees one amount arriving against an account with six open invoices, and allocates it by guessing.

Why each part is there

The fields are visible in the markup. What is not visible is why they are present, which is the part that gets removed first when someone adapts a template for their own use.

  • The bank reference and the payment date, which is how the recipient matches this advice to the money that arrived.
  • One row per invoice, with the invoice total, any deduction and the amount actually paid, because those three are frequently different.
  • Credit notes listed as negative rows in the same table, since that is how they were applied.
  • A total that equals the amount transferred, exactly. If it does not, the advice creates work rather than saving it.
  • A contact for queries that is a person or a mailbox rather than a bank reference, because bank references are shared across a whole payment run.

The template

A complete file. Doctype, stylesheet, body: paste it into a renderer unchanged and it produces a finished A4 page. Replace the sample data and the styling holds.

html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Remittance advice RA-2026-0612</title>
<style>
  @page { size: A4; margin: 20mm 18mm; }
  * { box-sizing: border-box; }
  body { margin: 0; font: 10pt/1.5 "Helvetica Neue", Arial, sans-serif; color: #111; }

  header { border-bottom: 2px solid #111; padding-bottom: 6mm; }
  h1 { margin: 0 0 1mm; font-size: 18pt; }
  .sub { color: #666; font-size: 9pt; }

  .payment { display: grid; grid-template-columns: 1fr auto; gap: 8mm; align-items: center;
             margin: 8mm 0; border: 1px solid #ddd; padding: 5mm 6mm; }
  .payment .amount { font-size: 22pt; font-weight: 700; font-variant-numeric: tabular-nums;
                     white-space: nowrap; }
  .payment dl { display: grid; grid-template-columns: auto 1fr; gap: 1.5mm 4mm; margin: 0;
                font-size: 9pt; }
  .payment dt { color: #666; }
  .payment dd { margin: 0; }

  .parties { display: grid; grid-template-columns: 1fr 1fr; gap: 10mm; margin-bottom: 8mm; }
  .parties h2 { margin: 0 0 2mm; font-size: 8pt; text-transform: uppercase;
                letter-spacing: 0.08em; color: #666; }
  address { font-style: normal; }

  /* This is the whole document. A payment that arrives without an allocation
     list has to be matched by hand, and the guess is often wrong. */
  table { width: 100%; border-collapse: collapse; }
  thead { display: table-header-group; }
  th { text-align: left; font-size: 8pt; text-transform: uppercase; color: #666;
       letter-spacing: 0.06em; border-bottom: 1px solid #111; padding-bottom: 2mm; }
  td { padding: 2.5mm 0; border-bottom: 1px solid #eee; }
  tr { break-inside: avoid; }
  .num { text-align: right; font-variant-numeric: tabular-nums; white-space: nowrap; }
  tfoot td { border-top: 1.5px solid #111; border-bottom: 0; font-weight: 700;
             padding-top: 3mm; font-size: 11pt; }

  .note { margin-top: 10mm; border-top: 1px solid #eee; padding-top: 5mm;
          font-size: 9pt; color: #444; break-inside: avoid; }
</style>
</head>
<body>
  <header>
    <h1>Remittance advice</h1>
    <div class="sub">RA-2026-0612 &middot; issued 08 May 2026</div>
  </header>

  <section class="parties">
    <div>
      <h2>From</h2>
      <address><strong>Calder Interiors Ltd</strong><br>
        7 Meridian Court, Leeds LS11 5AL<br>Accounts Payable</address>
    </div>
    <div>
      <h2>To</h2>
      <address><strong>Northgate Supply Co.</strong><br>
        18 Wharf Road, Bristol BS1 4RN<br>Attn: Accounts Receivable</address>
    </div>
  </section>

  <div class="payment">
    <dl>
      <dt>Payment date</dt><dd>08 May 2026</dd>
      <dt>Method</dt><dd>BACS</dd>
      <dt>Bank reference</dt><dd>BACS 88104</dd>
      <dt>Your account</dt><dd>NG-4471</dd>
    </dl>
    <div class="amount">GBP 4,102.40</div>
  </div>

  <table>
    <thead>
      <tr><th>Invoice</th><th>Invoice date</th><th>Description</th>
          <th class="num">Invoice total</th><th class="num">Deduction</th>
          <th class="num">Paid</th></tr>
    </thead>
    <tbody>
      <tr><td>INV-2026-0140</td><td>02 Apr 2026</td><td>Panel order, March</td>
          <td class="num">2,880.00</td><td class="num">0.00</td><td class="num">2,880.00</td></tr>
      <tr><td>INV-2026-0151</td><td>11 Apr 2026</td><td>Edge banding</td>
          <td class="num">1,308.00</td><td class="num">0.00</td><td class="num">1,308.00</td></tr>
      <tr><td>CN-2026-0038</td><td>18 Apr 2026</td><td>Credit, short delivery</td>
          <td class="num">-85.60</td><td class="num">0.00</td><td class="num">-85.60</td></tr>
    </tbody>
    <tfoot>
      <tr><td colspan="5">Total remitted</td><td class="num">4,102.40</td></tr>
    </tfoot>
  </table>

  <p class="note">
    This advice covers the payment in full and no invoices are part paid. If your
    ledger shows a difference, the discrepancy is on invoice INV-2026-0151 where a
    delivery charge was credited under CN-2026-0038. Contact ap@calderinteriors.example
    quoting RA-2026-0612 rather than the bank reference, because the bank reference
    is shared by every payment in the same run.
  </p>
</body>
</html>

The layout decision worth understanding

The payment amount is set large and next to the bank reference, in a bordered block, because those two fields together are the matching key. Everything below is the allocation. Rows carry break-inside: avoid, though with a typical payment run the whole document is one page.

The mistake people make adapting it

Sending the advice after the payment lands. Cash allocation happens the morning the money arrives, so an advice that turns up two days later is filed after the guess has already been made and the mis-allocation already exists.

Rendering it

The page box is declared in the template's own CSS as A4, so the size travels with the markup rather than living in the code that calls the renderer. A4 is also one of the six named formats the API accepts, so it can be passed in the request options instead if that suits your setup better.

bash
curl -X POST https://api.pdfpipe.xyz/v1/pdf \
  -H "Authorization: Bearer $PDFPIPE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<!doctype html>...",
    "options": { "format": "A4" }
  }' \
  --output remittance-advice.pdf

Frequently asked

Can I use this template commercially?

Yes. Copy it, change it, ship it. It is sample markup written to be taken, and the sample data in it is invented, so replace the names and the numbers before anyone sees it.

Why is the page size in the CSS rather than in the API call?

Because a remittance advice is a A4 document, and that is a property of the document rather than of the code that renders it. Declaring it in the page box means the size cannot be lost between the template and the call, which is the usual way a document ends up on the wrong paper.

Will it look the same in every renderer?

The layout will, because it uses ordinary CSS. The page break behaviour will not: break-inside and break-after are implemented differently by browser engines and by dedicated print engines, and some of the paged media specification is not implemented in browser renders at all. That difference is documented per property in the paged CSS reference.

Other templates

Documents from the same part of a business, and one from each of the other groups.

Paste the template into the playground and get the PDF back. No signup, no key.