Transaction
The transaction object describes why this payout is being made and the
evidence supporting it. The information is unique to each payout and is never
part of a saved party data map.
| Field | Type or format | Requiredness | Description |
|---|---|---|---|
transaction.purpose | String | Required | Business purpose of the payout. Supply an accepted Axiym value or descriptive text. |
transaction.sourceOfFunds | String | Required | Origin of the funds. Supply an accepted Axiym value or descriptive text. |
transaction.reference | String | Recommended | Remittance or invoice reference visible during reconciliation where supported. |
transaction.supportingDocuments[] | SupportingDocument[] | Required | One or more embedded supporting documents. |
purpose and sourceOfFunds are strings in the request. Axiym normalizes each
one to a final value from its controlled vocabulary before deterministic
validation. Exact accepted values pass through unchanged.
This is per-payout value normalization, not Party Data Map behavior. Transaction fields always use Axiym's documented structure and are never included in a saved map.
Example
{
"purpose": "payment for imported inventory",
"sourceOfFunds": "revenue from normal business operations",
"reference": "INV-2026-001",
"supportingDocuments": [
{
"documentType": "supplier invoice",
"documentDescription": "Invoice INV-2026-001",
"documentContentType": "application/pdf",
"documentData": "JVBERi0xLjQKJcTl8uXrCg=="
}
]
}The prepared payout might contain GOODS_PURCHASE, BUSINESS_REVENUE, and
INVOICE for the descriptive values above. Review the actual normalized result
rather than assuming a particular classification.
documentType is normalized in the same way. The document content remains
embedded in the payout request as base64.
See Value normalization for the complete preparation behavior, or use Test payout data to inspect representative results before creating a quote.
Why transaction data is not mapped
Sender and receiver records are often stored and reused in partner systems. Transaction data changes with every payout, especially its purpose, remittance reference, and supporting evidence. Keeping it in the standard request shape makes the instruction explicit, reviewable, and independent of a saved party record structure.