Sales, acquirer receivables and bank statement
Sale matches installment by transaction; installment matches credit by payout
Status per installment, effective fee and schedule to receive
Daily divergence list, month-end close and AI agent
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.
Business questions it answers
Ask your agent these questions once the case is live.
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
Where to activate
Late and divergent installments from the previous day, with expected amount, received amount and acquirer.
Answers about receipts, fees and the schedule with the release date rule already applied.
Reconciled receipts missing from the ERP become entries ready to settle, with the fee booked separately.
A well-connected acquirer reconciles quickly. Each new acquirer brings its own vocabulary and reports, and a spreadsheet statement needs date and number handling. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
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.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Status of each installment
Decided by the release date and by comparing expected and received net.
Definitions
Pitfalls that already happened
The payment provider's statement had an empty customer name on every card sale, and matching by name left those sales unmatched.
Look up the customer by the transaction number on the e-commerce order.
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.
Convert Brazilian-format dates and numbers before any filter and count the nulls.
Refunds made after the sync did not update the charge's refunded amount, and the sale stayed in the schedule as a receivable.
Read refunds and disputes from the acquirer's own tables.
The ERP created a companion bill for every card prepayment, with no real bank account, and the receivables portfolio appeared twice.
Consider only bills with a real bank account assigned.
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.
Write in the context document which connection belongs to each client.
Two accounts of the same provider arrived with different names and the report showed two acquirers with half the volume each.
Group by the canonical name from the acquirer mapping.
Acceptance test
The case is done when every item passes.
- 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%).
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
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.
Build the "Automatic card reconciliation" case in my Nekt workspace following the rules at https://academy.nekt.com/en/casos/conciliacao-de-cartao.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
The marketplace payout replaces the acquirer's, with commission, freight and refunds as payout deductions.
Same rule with release in a few days and a fixed fee per transaction instead of a percentage.
A single receivables base with a canonical acquirer column and each one's contracted fee.