Split in anticipated payments

Anticipate charges with Split

When anticipating a charge with Split, take into account the Asaas fees and the anticipation fees in the amount available for transfer.

The Split is then validated or calculated on the final net amount after anticipation, and not on the gross amount of the charge.

Before requesting the anticipation

Check whether:

  • the charge has a Split configured;
  • the charge is eligible for anticipation;
  • the Split amount is compatible with the estimated net amount after fees;
  • your reconciliation takes into account the amount actually anticipated.

See the Anticipations guide.

📘

Important

In anticipated charges, the split must take into account the final net amount of the charge after deducting Asaas fees and anticipation fees.

Therefore, do not use the gross amount of the charge as the basis to validate the amount that will be transferred by split.

How it works

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
    A["Create charge with Split"] --> B["Simulate the anticipation"]
    B --> C["Calculate the final net amount"]
    C --> D["Validate the Split rule"]
    D --> E["Request the anticipation"]
    E --> F["Process the anticipation"]
    F --> G["Settle the Splits"]
    G --> H["Receive the Webhooks"]

    classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
    classDef validacao fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
    classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px

    class A inicio
    class B,C,D,E,F,G validacao
    class H sucesso

    linkStyle default stroke:#94A3B8,stroke-width:2px

You can simulate the anticipation before requesting it:

POST /v3/anticipations/simulate

See the Simulate anticipation endpoint.

🚧

Attention

In anticipated charges, the net amount after anticipation is the operational basis to validate or calculate the split.

This may reduce the amount available for transfer compared to the original net amount without anticipation.

Fixed-amount Split

For fixedValue, the configured amount must be compatible with the net amount available after the charge and anticipation fees.

Example:

Gross charge amount: R$ 100.00
Net amount after Asaas and anticipation fees: R$ 90.00
Configured fixed Split: R$ 95.00

In this scenario, the configured Split exceeds the R$ 90.00 available and needs to be adjusted.

Prefer to validate this relationship before requesting the anticipation.

Percentage Split

For percentualValue, the percentage is applied to the final net amount after anticipation.

Example:

Gross charge amount: R$ 100.00
Net amount after Asaas and anticipation fees: R$ 90.00
Configured percentage Split: 50%

Result:

Split calculation basis: R$ 90.00
Percentage: 50%
Split amount: R$ 45.00

With percentualValue = 100, the entire net amount available after anticipation will be allocated to the Split.

TypeHow to handle it in the anticipation
fixedValueValidate whether the amount fits within the final available net amount
percentualValueCalculate the percentage on the final net amount after anticipation
📘

Best practice

Before requesting the anticipation, validate whether the configured split rule is compatible with the estimated net amount after fees.

This reduces refusals and reconciliation discrepancies.

Block due to divergence

If the Splits amount exceeds the available net amount during anticipation processing, Asaas may block the amount due to divergence.

In this flow, track:

PAYMENT_SPLIT_DIVERGENCE_BLOCK

The adjustment must be made within 2 business days.

When the block ends, Asaas sends:

PAYMENT_SPLIT_DIVERGENCE_BLOCK_FINISHED

During a divergence block, updating the split may be allowed even for anticipated charges. In this scenario, no other field of the charge can be changed.

See the Update existing payment endpoint.

Automatic anticipation with fixed Split

In automatic credit card anticipation, when the fixed Split is defined when the charge is issued, the calculation takes into account the highest fee applicable to the card used.

Take this behavior into account when reconciling net amounts among recipients.

Track via Webhooks

Use payment events to track the processing:

EventWhat it indicates
PAYMENT_ANTICIPATEDThe charge was anticipated
PAYMENT_SPLIT_DONEA specific Split was settled
PAYMENT_SPLIT_DIVERGENCE_BLOCKThe amount was blocked due to divergence
PAYMENT_SPLIT_DIVERGENCE_BLOCK_FINISHEDThe divergence block has ended

PAYMENT_SPLIT_DONE is triggered individually for each settled Split.

See Payment events.

Next steps


Did this page help you?