Debtor and creditor, the two ends of every payment

The debtor is the party who owes the money and who instructs the payment, and the creditor is the party who is owed the money and who receives it. In a salary payment, the employer is the debtor and the employee is the creditor. In a supplier payment, the buyer is the debtor and the supplier is the creditor. The same legal person can be a debtor in one payment and a creditor in another, and the roles are defined by the payment, not by the person. ISO 20022 uses debtor and creditor as the standard terms, while older SWIFT MT messages use ordering customer and beneficiary, but the meaning is the same. The debtor and creditor each have an identity, an address, and an account, and those details must be captured accurately for the payment to succeed and for compliance checks to pass. A missing or misspelled creditor name, a wrong account number, or an incomplete address can cause the payment to be rejected, delayed for manual repair, or returned after processing. In cross border payments, the debtor and creditor details are also screened against sanctions lists, and a match, even a false one, can hold the payment for review. Analysts must therefore treat party data as a core part of the payment, not as a decorative extra. The relationship between debtor and creditor also defines the business context. A payment from a company to a supplier settles an invoice, a payment from a parent to a subsidiary moves internal funding, and a payment from a bank to another bank settles an interbank obligation. The remittance information, the invoice references, and the purpose codes all explain that context to the receiving party and to the banks in the chain. When you document a payment, always start with the debtor and creditor, their accounts, and the reason for the payment, because everything else in the message exists to serve those three facts. Worked example with real numbers: a manufacturer in Lyon owes a supplier in Munich EUR 120,000 for steel, invoice INV-2026-1187, due in 30 days. The manufacturer is the debtor, the supplier is the creditor, the amount is EUR 120,000, the currency is euros, and the payment is a SEPA Credit Transfer. The pacs.008. If the manufacturer had sent EUR 100,000, the supplier would have EUR 20,000 outstanding, and the invoice would stay open. The debtor and creditor are therefore not just names on a screen, they are the parties to the underlying obligation, and the payment message must carry them exactly as they appear on the invoice. Failure and recovery: a payment sent by the wrong debtor, for example a subsidiary paying an invoice that belongs to the parent, will be rejected by the creditor reconciliation, because the debtor name does not match the invoice, and the recovery is a new payment from the correct debtor, with the correct reference. A payment sent to the wrong creditor, because the IBAN was correct but belonged to a different person, is recovered by a recall with a camt.056. A payment where the debtor and creditor are the same person, a payment to oneself, is a valid transfer but not a settlement of an obligation, and the system must not treat it as a supplier payment for reconciliation. Each failure is a party error, and the fix is in the party data, not in the amount. For a business analyst, product owner or subject matter expert, the test is to name the debtor and the creditor for every payment, with their legal names, their accounts and their roles, and to state how the payment is matched to the underlying obligation. The ISO 20022 pacs.008 carries the debtor and creditor as structured parties, with name, address and account, and the end to end identifier links the payment to the invoice, so the requirement must map the business parties to the message fields, and must state what happens when the debtor or creditor is wrong. A requirement that says payer and payee, without naming the legal parties, will fail its first reconciliation test, because the beneficiary cannot match a payment to an invoice from a nickname.