> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Payment Instructions Safety

> Why Arcus warns when your Payment Instructions look like banking credentials, what the warning checks for, and what to write instead.

The **Payment Instructions** field in **Settings > Entity Settings > Documents and Email** prints at
the bottom of every customer-facing Invoice, Quote, and Sales Order PDF. Anyone who receives one of
those PDFs can read it, forward it, or store it.

If you type bank routing or account numbers into that field, Arcus shows a warning before saving.
This page explains why, what the check looks for, and what to write instead.

<Warning>
  **Why routing and account numbers on a PDF are risky**
  In the US, a 9-digit ABA routing number plus an 8 to 17 digit account number is enough
  information to initiate an ACH debit against that account at most banks. It is a payment
  instruction, not a password, so there is no PIN or second factor protecting it. Once those two
  numbers are on a document that leaves your control, anyone who has the document has what they
  need to attempt an unauthorized withdrawal or to impersonate you in an invoice-redirection scam.
</Warning>

## What the warning looks like

When you type into Payment Instructions and the text matches one of the patterns below, an amber
panel appears under the field:

* Headline: **This looks like banking credentials**
* A list of what was detected, for example `routing number, account number`
* The safer alternatives described further down this page
* A link back to this article
* Two buttons: one to save anyway, one to dismiss the warning and keep editing

Nothing is saved until you choose. Dismissing the warning leaves your text in the editor so you can
change it.

## What the check looks for

Arcus scans the Payment Instructions text for five patterns. It never stores or logs the matched
text itself, only the name of the pattern that matched.

| Pattern                       | What it matches                                                                                     |
| ----------------------------- | --------------------------------------------------------------------------------------------------- |
| Routing number                | The words `routing`, `ABA`, or `ACH` next to a 9-digit number                                       |
| Account number                | The words `account` or `acct` next to an 8 to 17 digit number                                       |
| Routing plus account sequence | A bare 9-digit number followed on the same line by an 8 to 17 digit number, with no keywords at all |
| SWIFT/BIC code                | An 8 or 11 character bank identifier code                                                           |
| IBAN                          | A 2-letter country code, 2 check digits, then 11 to 30 alphanumeric characters                      |

<Note>
  **The check is deliberately conservative**
  It is tuned to avoid false alarms, so it can miss unusual formats (for example, a routing and
  account number split across two lines). Treat it as a safety net, not a guarantee. You are still
  responsible for what goes on a customer-facing document.
</Note>

## Safer alternatives

<CardGroup cols={2}>
  <Card title="Send a hosted pay link">
    Point customers at the payment page instead of a bank account. Card and ACH details are collected
    on the payment surface, not printed on a PDF.
  </Card>

  <Card title="Ask customers to contact you">
    For wire or ACH, write something like "Contact [accounting@example.com](mailto:accounting@example.com) for wire instructions" and
    send the details directly to the named person who asked.
  </Card>

  <Card title="State the payee and the method">
    "Make checks payable to Acme Corp, mail to 123 Main St" carries no credentials and is all a
    check-paying customer needs.
  </Card>

  <Card title="State the terms">
    Payment terms, accepted methods, late-fee policy, and a remit-to address are all appropriate here.
  </Card>
</CardGroup>

## Saving anyway

Some businesses genuinely need bank details on the document, and Arcus does not block you. Choosing
to save anyway is treated as an explicit acknowledgement of the risk and is written to the activity
log for the entity, so there is a record of who accepted it and when.

If you do save banking details, consider limiting who can send those PDFs and rotating the account
if a document is ever distributed more widely than intended.

## Where else this shows up

The same scan runs when a PDF is generated. If Payment Instructions still contain a matched pattern
at render time, Arcus records a warning in the server logs. This never blocks or delays the document
and is not visible to the customer; it exists so the risk stays visible to your team after the
initial save.

<Card title="Documents and Email Settings" href="/support/settings/documents-email">
  Where the Payment Instructions field lives, alongside quote, confirmation, invoice, and packing
  slip footer text.
</Card>