Skip to main content
Create a boleto receivable by defining the charge, payer, payment conditions, and boleto configuration. This guide focuses on the request body and explains how each part of the boleto works, especially the payment rules such as discounts, fines, and interest.
All examples use fictitious data.

Request body

A boleto request is mainly composed of:
The following example shows a complete boleto:
This example represents a R$ 100.00 boleto with:
  • due date on August 17, 2026;
  • 5% discount until August 16;
  • 1.5% fine after the due date;
  • 3% monthly interest after the due date.

Charge

The charge section defines what is being collected and how your system identifies the boleto.

amount

Defines the boleto amount. The value is sent in cents.
means:
Examples:
This is the original amount of the boleto. Discounts, fines, and interest are payment conditions that can change the amount the customer must pay depending on when the boleto is paid.

description

A short description of the charge.
Use it to identify what the customer is being charged for. For example:

external_id

An identifier generated by your own system.
It does not replace the Trio boleto ID. Instead, it allows your system to associate the boleto with an internal record. For example:
This is particularly useful for reconciliation.

Payer

The counterparty object identifies the person or company that will pay the boleto.
The fields describe the payer: The information should correspond to the actual payer associated with the boleto.

Payment conditions

The due_detail object is where the main payment rules are configured.
It controls what happens before, on, and after the due date.

Due date

due_detail.due_date

Defines the date on which the boleto becomes due.
In this example:
The due date is the reference point for the payment rules. Before this date, a discount may apply. After this date, the configured fine and interest may apply.

Discounts

A discount is a benefit given to the customer for paying before the due date. Discounts are configured inside:
The API supports two discount models:

Fixed discount before the due date

Use fixed_until_due when you want to define a specific discount for one or more dates before the due date. Example:
Here:
means 5%. For a R$ 100.00 boleto:
The discount is available on the configured date.

Different discounts for different dates

You can define multiple discount dates:
This represents:
This model is useful when the discount becomes smaller as the due date approaches.

Discount per anticipated day

The per_day_antecipated model calculates the discount based on how early the customer pays. Example:
Here:
  • amount defines the discount value;
  • calculation_type defines whether the value is an amount or percentage;
  • calculation_days defines how days are counted.
The available day calculation modes are:
Use working for working days or calendar for calendar days.

Discount calculation type

The discount can be calculated as:

Percentage

The value represents a percentage. For example:
means:

Fixed amount

The value represents a monetary amount.

Fine

The fine is a penalty applied when the boleto is paid after the due date. It is configured with:
There are two calculation types:

Percentage fine

represents a 1.5% fine. For a R$ 100.00 boleto:

Fixed fine

represents a fixed monetary fine. The important distinction is:

Interest

Interest is another charge that can apply after the due date. It is configured with:
The available calculation types are:
Each type determines how the interest value is interpreted.

Daily interest

The interest is configured as a daily rate.

Monthly interest

Here:
represents 3% per month. For a R$ 100.00 boleto, the configured monthly interest rate is:

Exempt from interest

Indicates that interest is exempt.

Bank-controlled interest

The interest calculation follows the bank-controlled configuration.

Fine vs. interest

Fine and interest are different concepts.

Fine

A penalty for paying after the due date.

Interest

A charge related to the period the payment remains overdue.
They can be configured together. For example:
means:

Boleto expiration

expiration_date

Defines the boleto expiration date.
This should be understood separately from the due date.
For example:
The boleto is due on August 17, while its expiration is October 30.

Receiving account

virtual_account_id

Identifies the virtual account associated with the boleto.
This is the virtual account that is associated with the boleto receivable. Always make sure the selected virtual account is the account intended to receive the payment.

Boleto type

The request contains two fields that define the boleto configuration:
These fields determine the type of document and wallet used for the boleto. Because there are multiple possible values and the correct combination depends on the boleto use case, the complete explanation is maintained in a dedicated guide. For details about invoice_type and wallet_type, open the Boleto Types guide. There you can find:
  • available invoice_type values;
  • available wallet_type values;
  • what each option represents;
  • when each type should be used;
  • examples of different boleto configurations.

Notes

notes

Optional additional information associated with the boleto. Example:
If there are no notes:
Use notes for additional information that does not need to be part of the main charge description.

Example: complete payment configuration

Suppose you want to create a boleto with:
The payment rules are:
The resulting behavior can be understood as:
* Assuming the 5% discount applies on the payment date and no other charge applies.

Complete request example

In this request: For more information about the document and wallet configuration, see the Boleto Types guide.