---
id: financeiros/conciliacao-recebimentos
industry: Financial services
usage: common
effort: medium
grain: Settled receipt x installment or contract, with status; settlement day for coverage
---

# Receivables reconciliation

Every payment the processor, bank or gateway settled matched to the installment posted in the core or the ERP, with duplicates, mismatched statuses and missing days visible before the day is closed.

## Executive summary

**For:** Lending fintechs, cooperatives, funding platforms and finance BPO firms that collect through a processor, boleto or gateway and need to close the day.

**What it solves**

- Every settled receipt has a match in the core or the ERP, or shows up on a list with the reason.
- Payments charged twice and statuses the system recorded wrong are caught the same day, not when the customer complains.
- A day missing from the processor report triggers an alert before it distorts revenue and cost.

**Why it matters:** In lending, money that came in and was not posted leaves the contract past due in the core and feeds the collection cadence and the PDD (loan-loss provision) by mistake. A duplicate payment becomes a refund, a chargeback and a complaint. And when the processor report arrives without a day, the month's revenue and cost come in below the invoice without anyone noticing.

**Business questions it answers**

- Which of yesterday's receipts have not been posted in the core or the ERP yet?
- How many customers were charged twice this week and how much do we need to refund?
- Was any day missing from the processor report this month?
- Do this month's capital contributions and buybacks match between the two systems?
- How much did we pay the processor in fees per settlement day?
- Which payments did the system mark as successful while the processor declined them?

**What you need**

- The settlement report from the processor, bank or gateway connected to Nekt (file, spreadsheet or API)
- Payments from the lending core or ERP installments with their postings
- The difference tolerance and the matching key agreed with the finance team

**What you get**

- A table per receipt with reconciliation status, both values and the difference
- Daily lists of unposted receipts, duplicates and inconsistent statuses
- Settlement report coverage history by settlement day, with an alert
- An AI agent that answers showing both sides

## Detailed

### The problem

The processor settles by settlement date, the core records by payment date and the ERP posts by financial account, each with its own identifier. Whoever adds up the three sides by month finds a difference nobody can explain. Whoever matches on amount without locking the pair matches the same line twice. And when a day's file does not arrive, or two collection platforms run in parallel, the number looks right and is wrong.

### Business rules

1. **The key is the transaction identifier.** Match on the id that exists on both sides: the transaction id at the processor, the boleto id on the collection platform, the order number at the gateway. When the ERP does not store that id, do it in two steps: first settlement date and gross amount, pairing one to one (each statement line matches a single installment); then, for what is left, normalized name and amount within up to 3 days. A different name with the same amount and date is not posted automatically: it goes to manual review. (Avoid: Matching on amount and letting the same installment match two statement lines.)
2. **Four statuses and a declared tolerance.** Each pair gets a status: matched (difference within tolerance, for example up to R$ 1.00), divergent (both values and the difference side by side), statement only, and core or ERP only. A divergence is not a pipeline error: it is a real disagreement between systems, and the table exists to show it. If the check is exact, with no tolerance, rounding also shows up as divergence, and that must be written down. (Avoid: Showing only one side's number or hiding the unmatched lines.)
3. **Settlement date, in Brasília time.** What moves the balance is the date the money was settled or transferred, not the payment or order date. Convert the date to America/Sao_Paulo before matching: the ERP often posts card receipts one day before the date the UTC spreadsheet shows. Keep the displayed date for the user and use the converted date only for matching. (Avoid: Matching on the order date or on the UTC date.)
4. **A duplicate payment has a fixed definition.** A duplicate is the same customer, with the same transaction id and the same amount, with two or more completed payments. For recurring fee or subscription charges, a second charge within 2 days of the first counts as a duplicate. Refunds are excluded, and so are test or validation entries with a token amount (up to R$ 1). (Avoid: Calling any customer with two payments in the month a duplicate.)
5. **Internal status against the processor response.** The core records success or failure in its own column, but the processor's raw response carries the real status. Read the status from the response, normalize it (hard and soft failures become error; success becomes completed) and list every day the payments where the two disagree. That is where the contract posted without money, or charged again, shows up. (Avoid: Trusting only the status recorded by the core.)
6. **Every settlement day needs a file.** Build the list of expected days in a rolling window (for example, the last 35 days, skipping the 2 most recent, which may still arrive) and mark each day as present or missing, with row and file counts. Save the result in append mode and alert when a day is missing. A day without a file leaves processor revenue and cost below the invoice. (Avoid: Assuming the report arrived complete because the pipeline ran without errors.)
7. **Payment components add up to the amount paid.** In a lending core, each payment splits into principal, interest, late fees and fees. The components must add up to the amount paid; when the file carries a residual, allocate it to a declared component (for example, principal) and flag the line. Reconcile the total with the processor and the components with the portfolio. (Avoid: Reconciling the total and letting the components add up to a different amount.)
8. **Two sources of the same receipt are not stacked.** During a processor or collection platform migration, the same payment appears in both sources. Stacking the two counts the charge twice. Deduplicate on the transaction id preferring the paid record, and cut by date: the old source up to the day before the switch, the new one from then on, excluding the day processed in both. (Avoid: Unioning the two collection sources and adding them up.)
9. **In the ERP, posting account, revenue and fees apart.** The receivable carries the expected account and the posting carries the account the money actually landed in; filter by the posting account. Add up only the revenue category: payment method fees, refunds and transfer fees are separate entries. Refunds and disputes use the net amount read straight from the statement line, never recalculated from gross. (Avoid: Adding up every category in the account registered on the receivable.)
10. **Posting back to the ERP is idempotent.** Before creating or settling any entry through the connector, list the day in the ERP and compare description and amount, counting occurrences. Create only what is missing; for what exists but is open, just settle it. Creation is often asynchronous and the connector has no delete: a duplicate entry can only be removed by hand. Then check the day: paid receivables equal the statement total, open equals zero. (Avoid: Rerunning entry creation after a rate-limit error.)

### Status of each receipt

Comparing the settlement report with the core or the ERP, one-to-one pair.

- **on both sides, difference within tolerance** → Matched (`|statement - core| <= tolerance`)
- **on both sides, difference above tolerance** → Divergent (`statement - core`)
- **settled with no match in the core or the ERP** → Statement only (not posted)
- **posted in the core or the ERP with no settlement** → Core only
- **same customer, transaction and amount, completed 2 or more times** → Duplicate
- **core status differs from the processor response** → Inconsistent status
- **same amount and date, different name** → Manual review
- **settlement day with no rows in the report** → Missing day

### Definitions

| Metric | Definition |
|---|---|
| Settled receipt | settlement report or statement line with money credited, by settlement date in America/Sao_Paulo |
| Posted receipt | payment recorded in the core or installment settlement in the ERP, in the posting account and the revenue category |
| Not posted | settled receipt with no match in the core or the ERP after both matching steps, by settlement day |
| Difference | statement amount minus core or ERP amount, per pair; above the declared tolerance it becomes divergent |
| Duplicate payment | second completed occurrence of the same customer, transaction id and amount; for recurring charges, a new charge within 2 days |
| Inconsistent status | payment whose normalized core status differs from the processor response status, by creation day |
| Report coverage | settlement days with at least one row / expected days in the window, per run |
| Processor cost | sum of per-transaction and network fees, by settlement day and transaction type |

### Pitfalls

- **Wrong category in the ERP.** Adding up every category in the gateway account, instead of revenue only, opened a gap of tens of thousands of reais in a month against the statement. How to avoid: Filter by the posting account and the revenue category.
- **Refund posted at gross.** A batch of refunds was created in the ERP at the gross amount instead of net. The connector has no delete, and the fix was manual, entry by entry. How to avoid: Read the net amount from the statement line and check the day before releasing the batch.
- **Cost below the invoice.** Days with no processor file dropped out of the cost calculation, which came in below the invoice without any pipeline error. How to avoid: Monitor coverage by settlement day and alert on the missing day.
- **Another client's connection.** At a BPO firm, one client's old ERP tables came from the wrong connection and carried another company's data. How to avoid: One documented connection per client, never reading or writing through another's.
- **Charge counted twice during a migration.** Two boleto platforms ran in parallel and a plain union added the same charge from both. How to avoid: Deduplicate on the transaction id, preferring the paid record, and cut by date.
- **Invalid key disappears silently.** Matching codes filled with junk, such as 0 or short numbers, left records out of the reconciliation without any warning. How to avoid: Validate the key format and list separately whatever was left out.

### Acceptance test

- [ ] For a closed day, matched plus divergent plus statement only has the same count and amount as the settlement report.
- [ ] No core or ERP line matches two statement lines, and no statement line matches two installments.
- [ ] For a checked day on the processor account, paid receivables in the ERP equal the statement total and open is zero.
- [ ] The coverage table has one row per settlement day in the window on every run, and every missing day triggered an alert.
- [ ] Running the automatic posting twice on the same day creates no new entry.

### Context document

```text
Receivables reconciliation
- Sides: settlement report from <processor/gateway> in <table> against <core/ERP> in <table>. Every answer shows both sides.
- Key: <transaction id>. Without it, step 1 by settlement date + gross amount, pairing one to one; step 2 by normalized name + amount, within 3 days. Different name with same amount and date goes to manual review.
- Status: matched (difference up to R$ <tolerance>), divergent (show both values and the difference), statement only (not posted), core only.
- Date: settlement date, converted to America/Sao_Paulo. Never the order date.
- Duplicate: same customer, same transaction id and same amount, completed 2 or more times. Recurring: second charge within 2 days. Refunds and amounts up to R$ 1 excluded.
- Inconsistent status: core status different from the processor response status.
- Coverage: every settlement day in the window needs a file. A missing day is a load failure, never a day without receipts.
- ERP: filter by the posting account and the revenue category. Fees, refunds and transfer fees are separate entries. Refunds at the statement's net amount.
- Counts (how many diverge, how many are not posted) are computed on the spot, with the load date. Never quote them from memory.
- Before any write to the ERP, list the day and create only what is missing. The connector has no delete.
Client exceptions:
- <client>: ERP connection <connection id>; never use another client's.
- <client>: collection platform <old> is valid until <date>; <new> from <date>.
- <client>: refunds posted in category <category>.
```

### Variations

- **Funding in two systems:** Capital contributions and buybacks from the finance control sheet against the operational base, by project and month, with contributions positive, buybacks negative and a R$ 1.00 tolerance.
- **Cooperative and insurance boletos:** Monthly quota or premium charges on two boleto platforms, deduplicated on the transaction id and matched to the member record.
- **BPO with an e-commerce gateway:** Gateway statement against the ERP installments of each of the firm's clients, with receipt, fee and refund posted through the connector.