---
title: "Create Bank Transaction for Payable"
method: POST
path: "/v1/erp/payouts/payables/{id}/create_transactions"
tags: ["Payable", "Banking"]
---

# Create Bank Transaction for Payable

`POST /v1/erp/payouts/payables/{id}/create_transactions`

## Request

- Base URL: `https://api.cardda.com`
- URL: `https://api.cardda.com/v1/erp/payouts/payables/{id}/create_transactions`
- Auth: HTTP bearer

Creates one or more bank transactions to pay a payable. This endpoint handles the creation of bank transfers from your company's bank account to a recipient's account, linking them to a specific payable.

## Important Notes
- The payable id is passed as a URL parameter in `/v1/erp/payouts/payables/{id}/create_transactions`
- Multiple transactions may be created if the amount exceeds bank limits
- Transactions are automatically linked to the payable for tracking

## Prerequisites
1. **Bank Account (sender_id)**: Your company must have a bank account configured
2. **Bank Recipient (recipient_id)**: The recipient must be registered and approved
3. **Bank Key**: User must have authorization to operate the bank account
4. **Payable**: The payable must exist and not be overpaid

## Authorization Flow
After creating transactions, they typically follow this status flow (may vary depending on bank):
- `draft` → `enqueued` → `preauthorized` → `approved`

`approved` is the terminal success state — there is no `authorized` or `completed` status.
(`authorize` is the name of the *transition* that lands a transfer in `approved`.) A rejected
transfer ends in `dequeued` or `declined`; a leg paid inside a payroll ends in
`payroll_authorized`. Poll on `status`, not on `transition`.

## Example Workflow
```
1. GET /v1/banking/bank_accounts to find your sender account
2. GET /v1/banking/bank_recipients to find or create recipient
3. POST /v1/erp/payouts/payables/{id}/create_transactions to create payment
4. Use banking authorization endpoints in /v1/banking/bank_accounts to approve the transaction
```

## Path parameters

- `id` string, uuid, required

## Parameters

- `#/paths/~1v1~1erp~1payouts~1rules/get/parameters/0` (unresolved $ref)

## Request body

- object
  - `sender_id` string, uuid, required: The UUID of your company's bank account (sender). Get this from GET /v1/banking/bank_accounts filtering by your company's RUT
  - `recipient_id` string, uuid, required: The UUID of the bank recipient who will receive the payment. Get this from GET /v1/banking/bank_recipients or create one if needed
  - `description` string, required: Description that will appear in the bank transfer. The base rule validates it against `/\A[A-zÀ-ú0-9 ]+\Z/` — `#`, `-`, `.`, `,`, `/`, `(` and `)` are rejected with `422 "Validation failed: Description is invalid"`, and there is no length limit at that layer. **The sending bank narrows it**, so a value that passes the base rule can still fail: 14 characters and letters/digits only at BICE (which strips and truncates silently rather than rejecting), 30 and no accents at BCI, 70 at Banco de Chile, Santander, Scotiabank, Itaú and the Cardda wallet. Over the cap you get `422 "Validation failed: Description is too long (maximum is N characters)"`. See the `description` field on [Create a bank transfer](https://docs.cardda.com/reference/createbanktransaction) for the full table. Independently of that, Banco Security, the BICE Connect path and STP print only the first 40 characters. The example below (31 characters, with spaces) is accepted everywhere except BICE, which would store it as `Pagofactura012`.
  - `amount` integer, required: Amount to pay, as an integer in the **minor unit of the sending account's currency**. CLP has no subunit, so `180000` is $180.000 — not $1.800. See [Amounts and currency](https://docs.cardda.com/docs/amounts-and-currency).
  - `bank_payroll_id` string, uuid: Optional - Link transaction to a payroll for batch processing
  - `lbtr` boolean: Optional - Use LBTR (Large Value Transfer System) for same-day high-value transfers

## Response `201`

Successfully created transaction(s). Returns an array of created bank transactions.
Multiple transactions may be returned if the amount exceeds bank limits.

- object[]
  - `id` string, uuid: Transaction UUID
  - `amount` integer: Transaction amount as an integer in the minor unit of the account's currency (whole pesos for CLP).
  - `status` 'draft' | 'enqueued' | 'dequeued' | 'preauthorized' | 'declined' | 'approved' | 'payroll_authorized': Current transaction status
  - `transition` 'enqueue' | 'dequeue' | 'preauthorize' | 'authorize' | 'remove' | 'null', nullable: Transition currently in flight, or `null` when none is
  - `description` string: Transaction description
  - `recipient` object
    - `account_number` string
    - `rut` string
    - `name` string
    - `bank_id` string
    - `email` string
  - `sender` object
    - `account_number` string
    - `bank_id` string
    - `rut` string
  - `created_at` string, date-time
  - `bank_payroll_id` string, uuid, nullable

## Other responses

- `400`: Bad Request - Invalid parameters or payable is overpaid
- `401`: Unauthorized - Missing or invalid authentication, or user lacks permission to operate the bank account
- `404`: Not Found - Payable, bank account, or recipient not found
- `422`: Unprocessable Entity - Validation errors

---

[API](https://skmtc.dev/cardda/apis/erp-api.md) - [All operations](https://skmtc.dev/cardda/apis/erp-api/llms.txt) - [OpenAPI document](https://skmtc.dev/cardda/apis/erp-api/revisions/0730ed26bc3c?raw)