Guides

Settling funds to a merchant: /transfers with "to settle"

Payment platforms, marketplaces and payment facilitators collect money on behalf of their merchants and later pay it out. In many countries the platform must withhold taxes on that payout as a collection agent. Examples: Argentina's IIBB payment-platform regimes and SIRTAC, Colombia's Retefuente and ReteICA, Dominican Republic's ITBIS withholding.

A to settle transfer tells Brinta: "I'm about to settle this amount to this merchant." Brinta returns the withholdings to apply before you pay it out.

📚

API reference: Create a transfer · Get a transfer · Update a transfer · Transfer webhooks

📘

Key things to know

  • type is spelled exactly "to settle": lowercase, with a space.
  • You (the platform) are the account holder. The merchant is the counterpart.
  • Taxes are calculated directly on each line's amount. There is no invoice behind it. Compare payment from invoice, which works from a supplier invoice.
  • Unlike payment from invoice, a to settle transfer can be updated with PUT.

Request

curl -X POST https://api.brinta.com/transfers/ \
  -H "Authorization: Bearer $BRINTA_TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-idempotency-key: 9e8d7c6b-5a49-4382-a1b0-c9d8e7f6a5b4" \
  -d '{
    "type": "to settle",
    "status": "created",
    "currency": "ARS",
    "transaction_date": "2026-07-10",
    "transaction_external_id": "SETTLE-2026-07-10-00042",
    "account_holder_company_id": "5c6e4b83-a032-11ee-a484-0a8bae22163d",
    "counterpart": { "company_id": "17d1d461-f707-423d-af8c-cf8cb5aef62a" },
    "payment_method": { "type": "credit card" },
    "items": [
      { "name": "Card sales settlement 2026-07-10", "amount": 187468.5, "categories": [{ "code": "out" }] }
    ]
  }'

Fields

FieldRequiredNotes
typeYes"to settle".
statusYesNormally created. Also accepted: pending, rejected, completed, paid.
currencyYesISO 4217.
counterpartYesThe merchant. Send exactly one of company_id, company_external_id or company.
items[]YesAt least one line with amount.
account_holder_company_id / account_holder_company_external_idNoThe platform. Defaults to the company that owns the token.
transaction_dateNoSettlement date. It decides which rates and padrón data are in force, and which month cumulative regimes use. Defaults to today.
transaction_external_idNoYour settlement or payout ID.
payment_methodNoSome regimes depend on the payment method. type can be credit card, debit card, prepaid card, digital wallet, bank transfer, cash or intermediaries.
exchange_rateNoFor non-local currency.
original_transaction_idNoLinks the settlement to an earlier transaction, for example the sale it settles.
use_tax_engineNoDefault true. Send false together with items[].taxes to record withholdings you calculated yourself.

The merchant (counterpart)

The merchant's data drives most of the result:

  • Address. address.state in ISO 3166-2, for example AR-C. Gross-income regimes are provincial, so the merchant's jurisdiction matters.
  • type. business or person.
  • tax_registrations[]. For example a CUIT, with status holding the merchant's tax condition.
  • Padrón memberships. These are the rates assigned to the merchant by each tax authority.

Create merchants once with POST /companies, then validate them with /tax-id-validations. Brinta stores their padrón memberships and rates, and every later to settle picks them up automatically through counterpart.company_id. The Argentina guide walks through this.

You can also send the merchant inline:

"counterpart": {
  "company": {
    "type": "business",
    "legal_name": "LinkedStore Argentina SRL",
    "external_id": "27428928283",
    "address": { "country": "AR", "state": "AR-C" },
    "tax_registrations": [ { "number": "27428928283", "type": "CUIT", "level": "country", "location": "AR" } ]
  }
}

Items

FieldNotes
amountThe amount being settled. Taxes are calculated on it.
categoriesDirection of the money: out (paid out by the account holder), in, international out or international in. Add any category your regimes need, for example an activity code or a location category such as { "list": "location", "code": "AR-C" }.
name, descriptionInformational.

Response

200 OK, abridged. A CABA merchant settled by a platform that is an agent for CABA IIBB payment platforms and for SIRTAC:

{
  "id": "6f1e2d3c-4b5a-4968-8776-655443322110",
  "type": "to settle",
  "status": "created",
  "account_holder_company_id": "5c6e4b83-a032-11ee-a484-0a8bae22163d",
  "transaction_date": "2026-07-10",
  "currency": "ARS",
  "amount": 187468.5,
  "final_amount": 177157.74,
  "items": [
    {
      "name": "Card sales settlement 2026-07-10",
      "amount": 187468.5,
      "final_amount": 177157.74,
      "categories": [{ "code": "out" }],
      "taxes": [
        { "name": "Retención IIBB - CABA - Régimen Especial Plataformas de Pago", "rate": -0.025,
          "taxable_amount": 187468.5, "amount": -4686.71, "level": "state", "location": "AR-C",
          "withholding_type": "WITHHOLDING", "adds_to_final_amount": true },
        { "name": "Retención SIRTAC", "rate": -0.03,
          "taxable_amount": 187468.5, "amount": -5624.05, "level": "state", "location": "AR-C",
          "withholding_type": "WITHHOLDING", "adds_to_final_amount": true }
      ]
    }
  ]
}

How to read it:

  • Each withholding has withholding_type: "WITHHOLDING" and a negative rate and amount.
  • final_amount is what you pay the merchant: 187,468.50 − 4,686.71 − 5,624.05 = 177,157.74.
  • final_amount − amount is the total withheld, which you pay to the authorities.

Updating a settlement

curl -X PUT https://api.brinta.com/transfers/6f1e2d3c-4b5a-4968-8776-655443322110 \
  -H "Authorization: Bearer $BRINTA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "status": "paid" }'
  • PUT /transfers/{id} accepts status (created, rejected or paid), approval_status and payment_method.
  • It does not recalculate taxes. To correct amounts, reject the settlement and send a new one.

To be notified of status changes, subscribe to the transfer webhooks (pending, created, rejected).

Choosing the right transfer type

typeUse it for
to settleFunds collected for a merchant that you are about to pay out. Withholdings are calculated on the payout.
settlementThe actual payout, when you record it separately from to settle.
payment from invoicePaying a supplier's invoice. Withholdings are based on the invoice. See the payment from invoice guide.
transferAny other movement of funds, for example bank debits and credits subject to ICDB.
transfer reversalReversing an earlier transfer. Link it with original_transaction_id.
💡

Cumulative regimes such as Argentina's Ganancias RG 830 add up to settle, settlement and payment from invoice amounts to the same counterpart in the calendar month. If you send both a to settle and a settlement for the same money, the amount counts twice. Use one of the two consistently.

Common mistakes

MistakeFix
"type": "to_settle" or "settle"Use "to settle".
counterpart sent as an array, or items nested inside itcounterpart is an object. items sits at the top level.
Merchant without address or tax registrationWithholdings are often provincial and status-based. Send address.state and the CUIT, or validate the merchant first.
Expecting PUT to recalculateReject and resend.
Typos in field names/transfers ignores unknown fields instead of rejecting them. A misspelled field is silently dropped, so check field names against this guide.

Updated about 9 hours ago

Did this page help you?