---
id: casos/conciliacao-de-cartao
area: Finance
usage: common
effort: medium
grain: Transaction x installment x acquirer
---

# Automatic card reconciliation

Every card sale matched to the installment the acquirer released and to the bank credit, with fees, prepayment and what has not landed yet on every row.

## Executive summary

**For:** Finance teams at companies that sell by card through one or more acquirers and reconcile in spreadsheets.

**What it solves**

- Every sale has its installment at the acquirer and its bank credit, or a reason it does not.
- The fee charged on each installment is compared with the contracted fee.
- What should have landed and did not shows up the next day, not at close.

**Why it matters:** The amount that reaches the account is never the sale amount: fees, installments, prepayment, refunds and standalone charges sit in between. Without reconciling installment by installment, a company finds overcharged fees and receivables that never landed only when cash runs short. The same base feeds the P&L with the real fee and the cash forecast with the receivables schedule.

**Business questions it answers**

- How much did we sell by card yesterday and how much has reached the account?
- Which sales have not been received and should have been?
- What effective fee did we pay each acquirer this month?
- How much did we pay for prepayment this quarter?
- How much card money will we receive over the next few weeks?
- Which receipts reached the bank and were not settled in the ERP?

**What you need**

- The acquirer or gateway connected to Nekt (transactions, installments, payouts and fees) or its statement in a spreadsheet
- ERP or e-commerce sales with the transaction identifier
- The table of contracted fees by acquirer, card brand and number of installments

**What you get**

- A table per installment with gross, fees, expected net, received net and status
- Card receivables schedule by release date
- A daily list of divergences and late installments
- An AI agent that answers about receipts with the right rule

## Detailed

### The problem

A R$ 1,200 sale in 6 installments becomes six receivables with their own dates and fees, and the bank receives a payout that bundles several sales from several days. Whoever compares the sale with the day's credit finds no match at all; whoever matches by customer name finds that card transactions carry no name. Refunds, chargebacks, prepayments and standalone fees make up the gap nobody can explain at close.

### Business rules

1. **Three sides, two reconciliations.** The sale (order or invoice) matches the acquirer receivable by transaction. The receivable matches the statement credit by payout batch (payout, release, settlement). These are two different reconciliations: the first proves every sale became a receivable, the second proves every receivable became money in the account. (Avoid: Comparing the day's total sales with the day's total credits.)
2. **The grain is the installment.** An installment sale creates one row per installment, each with its own release date, amount and fee. Reconcile at transaction x installment grain and aggregate afterwards. The sale only closes when every installment is reconciled or refunded. (Avoid: Expecting the full sale amount in a single credit.)
3. **The key is the transaction identifier.** Store the acquirer identifier on the sale (NSU, TID, charge or transaction id) and match on it. When it does not exist, match on date and gross amount with one-to-one pairing: each acquirer row can match only one sale. Never match on customer name: for cards it usually comes empty in the statement. (Avoid: Matching on customer name or on amount without preventing the same row from matching twice.)
4. **Net is gross minus every fee.** Net = gross amount - processing fee (MDR) - prepayment fee - other per-transaction fees (anti-fraud, for example). Compare the received net with the expected net from the contracted table. Declare the tolerance (cents or up to R$ 1.00) and show both values when there is a divergence. (Avoid: Comparing the sale's gross amount with the credited amount.)
5. **The date that matters is the release date.** Each installment's status is decided by the date the money becomes available, not the sale date. Cards usually release about 30 days per installment; prepayment brings the date forward and charges its own fee; Pix and boleto release in a few days. When the acquirer does not provide the date for a one-time receivable, use the transaction date plus one banking business day, with a holiday calendar. (Avoid: Flagging as late every sale that did not land the same day.)
6. **Refunds and chargebacks come from their own objects.** Read refunds, disputes and chargebacks from the acquirer's own tables. The refunded amount field on the charge is not updated when the refund happens after the sync. Refund amounts are negative, and installments of a refunded sale leave the receivables schedule. (Avoid: Trusting the refund field stored on the charge.)
7. **Standalone fees are also a cost.** Besides each transaction's fee, the acquirer charges fees on their own rows: withdrawal, transfer, monthly, service fees. They belong to no sale, but they reduce the payout and are part of the cost of payments. Reconcile these rows against the statement and add them to the month's effective fee. (Avoid: Computing the effective fee from per-transaction fees only.)
8. **In the ERP, the settlement account wins.** In the ERP, the bill carries the expected financial account and the settlement carries the account where the money actually landed, and the two can differ. To know how much was received per acquirer or channel, filter by the settlement account. Companion bills created for card prepayments, with no real bank account, are excluded so nothing is duplicated. (Avoid: Filtering receipts by the account set on the bill.)
9. **Acquirer normalized through a mapping.** The gateway name arrives with variations (lowercase, two accounts of the same provider, empty). Keep a mapping to a canonical name, with a fixed value for no acquirer. A new gateway lands in unmapped and triggers an alert, instead of vanishing from the sums. (Avoid: Grouping by the raw gateway text.)

### Status of each installment

Decided by the release date and by comparing expected and received net.

- **Sale, installment and credit matched, difference within tolerance** → Reconciled
- **Matched, but received net differs from expected** → Divergent (`expected - received`)
- **Release date still in the future** → Receivable
- **Release date passed and the credit did not come** → Late
- **Installment of a refunded or disputed sale** → Refunded (`leaves the schedule`)
- **Receivable or credit with no sale or settlement in the ERP** → Acquirer only
- **Card sale with no transaction at the acquirer** → ERP only

### Definitions

| Metric | Definition |
|---|---|
| Gross amount | amount of the transaction installment before any fee, by acquirer and sale date |
| Processing fee (MDR) | amount the acquirer deducts from each installment, by card brand, product and number of installments |
| Prepayment fee | amount deducted to release the installment before its original date, per prepaid installment |
| Expected net | gross minus contracted fees, per installment, on the expected release date |
| Received net | amount actually released or credited for the installment, from the acquirer's payout report |
| Divergence | expected net minus received net, per installment; outside the declared tolerance it becomes divergent status |
| Effective fee | sum of per-transaction fees, prepayment fees and standalone fees / sum of gross amount, by acquirer and month, summing before dividing |
| Schedule to receive | sum of expected net for installments with a future release date, by day, excluding refunded sales |

### Pitfalls

- **Card with no customer name.** The payment provider's statement had an empty customer name on every card sale, and matching by name left those sales unmatched. How to avoid: Look up the customer by the transaction number on the e-commerce order.
- **Statement as text.** The statement came from a spreadsheet with dd/mm/yyyy dates and comma decimals, all as text. Converted directly, amounts with a thousands separator became null and left the sum without any error. How to avoid: Convert Brazilian-format dates and numbers before any filter and count the nulls.
- **A refund that never showed.** Refunds made after the sync did not update the charge's refunded amount, and the sale stayed in the schedule as a receivable. How to avoid: Read refunds and disputes from the acquirer's own tables.
- **Receivables with duplicate bills.** The ERP created a companion bill for every card prepayment, with no real bank account, and the receivables portfolio appeared twice. How to avoid: Consider only bills with a real bank account assigned.
- **Another client's connection.** At a finance outsourcing firm, one client's tables came from an ERP connection that belonged to another client, and receipts were reconciled against the wrong portfolio. How to avoid: Write in the context document which connection belongs to each client.
- **Same acquirer, two names.** Two accounts of the same provider arrived with different names and the report showed two acquirers with half the volume each. How to avoid: Group by the canonical name from the acquirer mapping.

Validated on real data: In Nekt's own Stripe account, net was exactly amount minus fee on every balance transaction, but most card charges only became available 29 days after the sale, against 1 to 4 days for boleto. And fees booked on their own rows, outside the charges, added up to about 15% of the fees embedded in sales: looking only at each transaction's fee underestimates the cost of payments.

### Acceptance test

- [ ] For a closed month, reconciled payouts plus standalone fees plus refunds equal the total the acquirer credited on the bank statement, with no difference or with the difference explained.
- [ ] Each acquirer installment matches at most one sale, and no sale matches another sale's installments.
- [ ] Gross minus fees equals net on every acquirer row.
- [ ] No installment of a refunded sale appears as receivable or late.
- [ ] The month's effective fee per acquirer matches the acquirer's own report (difference below 0.5%).

### Context document

```text
Card reconciliation
- Grain: transaction x installment x acquirer. An installment sale has one row per installment.
- Sale matches installment by transaction identifier (NSU, TID, charge id). Without an identifier: date + gross amount, one-to-one pairing. Never by customer name.
- Installment matches the statement by the acquirer's payout batch.
- Net = gross - processing fee - prepayment fee - other fees. Compare with the expected net from the contracted table. Tolerance: <tolerance>.
- Status by release date: receivable before it, late after it with no credit.
- Refunds and chargebacks come from the refund and dispute tables, as negative values. A refunded sale leaves the schedule.
- Standalone fees (withdrawal, transfer, monthly) count in the month's effective fee.
- In the ERP, received per channel = settlement account, not the bill's account.
- Always use the canonical acquirer name from the mapping.
- Effective fee = sum of all fees / sum of gross, summing before dividing.
- Margin uses the fee as a cost; reconciliation compares expected with received. Do not treat the two as the same number.
Client exceptions:
- <client>: the ERP connection is <connection>; do not use other clients' connections.
- <client>: acquirer <name> sends its statement as a spreadsheet on <day and time>; before that the day shows as receivable.
```

### Variations

- **Marketplace:** The marketplace payout replaces the acquirer's, with commission, freight and refunds as payout deductions.
- **Pix and boleto:** Same rule with release in a few days and a fixed fee per transaction instead of a percentage.
- **Several acquirers:** A single receivables base with a canonical acquirer column and each one's contracted fee.