Payment Details on PDFs
The fastest way to get paid late is an invoice that doesn't say how to pay. The Payment Details panel fixes that: a standing block of remittance instructions — bank name, account, wire references, even a payment QR code — printed on every generated document from that template. Write it once; every invoice carries it.
Access you'll need. Setting up templates requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view templates but not change them.
Setting it up
Open the entity's template and fill Payment Details
It's a rich-text field on the PDF Template — formatting, tables, links, and images (a scan-to-pay QR code) all work. Meridian's reads: Payment by ACH or wire: First National Bank — Operating · Account 4400187233 · Reference your invoice number with every payment.
Leave Show Payment Details on
The panel prints when the template resolves, the field has content, and the toggle is on. It renders as a highlighted "Payment Details" section after the totals — where the reader's eye lands right after seeing what they owe.
Where the panel prints
The panel renders under its own Payment Details heading on a shaded panel — the template's secondary color — placed after the totals and tax breakdown, exactly where a reader who has just seen the amount looks for what to do about it. It prints on every document the engine generates from that template's type: invoices, credit memos, receipts, payment vouchers, purchase orders. It does not print on the statement of account — a statement summarizes many documents, each of which already carried its instructions. The field itself is roomy: up to 8,000 characters of formatted text, comfortably enough for domestic and international remittance blocks side by side.
Three conditions must all hold for the panel to appear, which doubles as the troubleshooting list:
| Condition | How to check |
|---|---|
| A template resolved | The generation screen's Template row names one — an italic Default means the built-in layout, which has no panel at all |
| The field has content | Open that template and look at Payment Details — remember territory fallback templates need the block too, not just your flagship entity template |
| Show Payment Details is on | The toggle sits with the template's other show/hide checkboxes; it starts on, but check it wasn't cleared |
Design notes
- It's per template — which is exactly right: each entity (and each region, via territory templates) banks differently, so instructions follow the template hierarchy automatically. US invoices carry US bank details; UK invoices carry Barclays.
- It's static text, deliberately. The panel prints what you wrote — it doesn't read from bank-account records, so review it whenever banking arrangements change. (Treasury teams prefer this: what prints on invoices changes only by explicit edit.)
- Tell them the reference. The single highest-value line is "reference your invoice number" — it's what lets receipt matching take seconds instead of archaeology.
- Different needs per document type: invoices get full remittance instructions; a receipt template usually leaves the field blank (the customer already paid); the payment-voucher template might carry your remittance-advice contact instead.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Changing bank accounts in banking setup and calling it done | The panel is standing text — it keeps printing the old account on every new invoice, and customers keep paying into it | Put "update Payment Details on every affected template, regenerate one proof" on the bank-change checklist itself |
| Writing the block once and forgetting the fallback templates | Entities served by a territory template print that template's panel — blank or wrong details on exactly the paper nobody proofreads | Maintain Payment Details on territory templates with the same care as entity ones |
| Copying the invoice's instructions onto every template type | A receipt telling an already-paid customer how to pay reads careless; a purchase order carrying your own bank details is worse | Tailor per type — full remittance block on invoices, blank (or a contact line) on receipts and vouchers |
| Skipping the reference instruction | Payments arrive that match no invoice, and someone reconstructs intent by email archaeology | Make "Reference your invoice number with every payment" the one line you never cut |
| Shipping a QR code no one scanned | A misgenerated or stale code sends payers to a dead end — with your name on it | Regenerate one document and scan-test the code on paper and on screen before rollout |
Where to go next
- PDF Template Configuration — the rest of the template.
- Admin-Configurable PDF Columns — surfacing record fields (like the receipt's bank) instead of static text.
- Sales Invoice PDF — where your customer sees the panel.
Frequently asked questions
The panel itself is standing text. To print a record field (say, the receipt's actual bank account), your administrator adds it to the document's PDF detail fields — see Admin-Configurable PDF Columns. Many organizations use both: fields for facts, the panel for instructions.
Yes — the field is rich text, so paste an image. Generate one document and scan-test it before rolling out.
Three conditions must hold: a template resolved (the built-in default has no panel), the field isn't blank, and Show Payment Details is on. The generation screen names the resolved template — start there.
Instructions follow the template, so the lever is template choice: language/locale-tagged templates differentiate by customer language automatically, and for a true one-off, set the document's own PDF Template field to a template carrying the special block.
No — the statement takes its branding, terms, and footer from a Statement-type template, but payment details stay on the transaction documents themselves. Each invoice on the statement already went out carrying its instructions.
Files already generated stay as issued. New generations print the new block immediately; regenerating an existing document adds a new version with the updated panel — and its public link, if any, serves that newest version.
Was this article helpful?