Extract data from payment orders

A payment order is the instruction a company sends its bank to move money: pay these beneficiaries, from this account, on this date, for these amounts. In the ISO 20022 world the message is pain.001, a Customer Credit Transfer Initiation, and it carries a group header with a control sum and a count of transactions, then one block per payment naming the payee, the creditor IBAN and BIC, the amount, and an end-to-end reference the payer assigns and the banking chain passes back unchanged. A treasury analyst releasing a batch, an accounts payable clerk reconciling it later, and an auditor tracing a payment to its invoice all read the same structure: who paid whom, how much, in which currency, and against which invoice. Payment orders arrive as bank PDFs, ERP payment proposals, and printed pain.001 summaries, and the reconciliation detail is what makes them hard. A batch dated 2026-06-15 for value on 2026-06-18 might total EUR 25,000.00 across three credit transfers, each tied to a supplier invoice through a structured creditor reference in the ISO 11649 RF format, and the remitted amount on a line can sit below the due-and-payable amount when a deduction or a short payment applies. IBANs, BICs, and routing numbers have to come off cleanly for the payment to clear, the payment method (SEPA credit transfer, ACH, wire, or check) changes which fields matter, and the end-to-end ID is the thread that lets a later camt statement be matched back to this order. Reading a payment file into a chatbot risks a transposed IBAN; the numbers have to be exact.

What gets extracted from payment orders

How extraction works for payment orders

Payment orders come from bank portals, ERP payment runs, and pain.001 files rendered as PDFs, and the party and account details are spread across a group header and per-transaction blocks. Talonic classifies the order and maps it to the payments model in the Field Registry, which separates the payer and payee, their IBAN and BIC, the account and routing numbers, and the amounts, and returns the settled invoices as a paid-invoices array. The control sum is checked to foot against the sum of the transaction amounts, structured creditor references in the ISO 11649 format are kept for reconciliation, and end-to-end IDs are preserved so a downstream camt statement can be matched to the order. Amounts are typed in the stated currency and account identifiers are read character by character. Every value returns with a confidence score and a pixel-region pointer conforming to DIN SPEC 91491, so a treasury analyst can verify a beneficiary IBAN or a control sum against the source before the batch is released.

Sample extraction

A three-transaction SEPA credit-transfer payment order with remittance detail

{
  "document_number": "PMT-2026-06-3391",
  "document_date": "2026-06-15",
  "payment_date": "2026-06-18",
  "payer.name": "Baumann Fertigung GmbH",
  "payer.iban": "DE89370400440532013000",
  "payer.bic": "COBADEFFXXX",
  "currency": "EUR",
  "total_amount": 25000,
  "number_of_transactions": 3,
  "payment_method": "SEPA credit transfer",
  "note": "Control sum 25,000.00 = 12,450.00 + 8,200.00 + 4,350.00",
  "paid_invoices": [
    {
      "payee.name": "Rhein Chemie GmbH",
      "invoice_number": "RC-8841",
      "due_payable_amount": 12450,
      "remitted_amount": 12450,
      "currency": "EUR",
      "structured_creditor_reference": "RF18 5390 0754 7034",
      "end_to_end_id": "E2E-INV-4471"
    },
    {
      "payee.name": "Meridian Freight",
      "invoice_number": "MF-2231",
      "due_payable_amount": 8500,
      "remitted_amount": 8200,
      "currency": "EUR",
      "structured_creditor_reference": "RF47 1102 9987 6612",
      "end_to_end_id": "E2E-INV-4472"
    }
  ]
}

Frequently asked