📘 Screen: Payment batch

A payment batch is the set of installments someone decided to pay together. It covers the gap between "I decided to pay" and "the money went out" — the stretch that used to have no place in the system, where an installment was either open or already settled, with nothing in between.

In practice it is the weekly payment routine: on Thursday someone picks out the installments coming due, sends the batch for approval by whoever the company has designated, generates the file that is uploaded to the bank's online banking and, with the bank's response in hand, settles what was actually paid. Each of these steps has a batch status, and that is what the screen shows.

📍 Location in the system

Menu: Financial > Payment batch

It closes the day-to-day block of the Financial menu, after Transfer between accounts. Like every screen in the web portal, it only appears for those who have permission, granted in File > Users.

Two screens work alongside it: Approval rules, which says who approves each value range, and Accounts Payable/Receivable, where the installments come from and where the settlement actually happens.

🧩 Main function

To group installments payable, run them through the company's approval, send the payments to the bank in a file and settle them from the bank's response. The batch does not create documents or installments: it points to installments that already exist in Accounts Payable/Receivable, and the installment remains the source of truth for what is owed.

The batch cycle

Who can do what

The screen permission (File > Users) splits the actions like this:

• Add — create the batch, add installments and send for approval.
• Edit — change the header, remove an installment, reject an item, go back to draft, export the payment file, import the return file, reconcile and settle.
• Delete — delete the batch (a paid batch cannot be deleted).

📝 Main fields

Above the fields is the status badge, and next to it a line that changes depending on where the batch is: the current step and who approves, while it is in approval; "Approved by John Doe - 10/03/2026 (rule: Above R$ 100k)", once approved; "Payment file 12 - CI240_001_000012.REM - generated by John Doe on 10/04/2026", when the file went out; and "Returned by John Doe - 10/03/2026: freight invoice missing", when it went back to draft. Once the bank's return file is read, the name of the .RET file is added after that, without erasing the payment file's — the normal check is to compare the two.

The list, on the left, shows Number, Date, Description, Bank account, Status, Current step, Installments, Total amount, Management account, Cost center, Origin, Notes and an Actions column. The three middle columns show (several) when the batch's installments do not converge on a single value — that is how you can see, without opening the batch, that it mixes expenses of different kinds. The filter above the list switches between All and Awaiting my approval.

🗂 Tab: Installments

This is the list of what the batch will pay. Each line is an installment from Accounts Payable/Receivable, with Document, Entity, Installment, Due date, Amount (the installment's), Amount to pay (what you intend to pay through this batch), Status, How it will be paid, Your number, Occurrence and the line's actions. At the bottom, the total of what is in effect and the number of installments.

The status is per item, on purpose: the bank rejects one line and accepts the others in the same file. Pending, Paid and Rejected — and a rejected one, in red, stays in the list but does not count toward the total.

Add installments

The Add installments button opens the selection. Only installments that can be added appear, and the dialog's help text says which: "Only open accounts payable installments that are not already in another batch appear" — from the farm you are in, with a due date in the chosen period (which starts one year back through one month ahead).

The grid shows Document, Entity, Installment, Due date, Amount, Account and Term, which flags what is Overdue and what is Short term (due within seven days). At the bottom, two summaries: Total open, for what the filter found, and Selected, which follows your selections item by item — you can see the batch amount before confirming.

Removing an installment from the batch

Here a rule applies that seems odd and is deliberate: removing is allowed, adding is not.

• Add installments only in draft. In approval, changing the list under a signature in progress is exactly what step-by-step approval exists to prevent; once approved, adding would raise the authorized amount.
• Removing an installment works in draft and in an approved batch, before settlement. Removing only reduces what was authorized, and whoever signed a R$ 100k batch has no objection to paying R$ 80k of it. Previously, removing a line from an approved batch forced the whole approval to be redone — and, in practice, it was redone in a hurry, without anyone reviewing anything.
• An installment that has already been paid never leaves the batch. It is the settlement's history: "This installment has already been paid and can no longer leave the batch."

Reject an item

The Reject button, on the installment's line, serves a single case: the bank refused that line — wrong PIX key, invalid account, payee details that don't match. The dialog's help text states the effect: "The installment stays open and can go into another batch again; nothing is settled or reversed."

The reason is required, and it goes into the Occurrence column. It is the only record of why that payment did not happen — without it, months later, the rejected line is a mystery, and someone puts it back into a batch without knowing the problem was the supplier's record.

Rejecting only exists from an approved batch on (approved, payment file generated, sent or paid), which is when there is already a bank response to record. In draft and in approval nothing has been sent, and there the way to remove a line is to delete the item — an occurrence would be a made-up justification for something the bank never saw. An installment that has already been paid cannot be rejected either: the money went out, and saying the bank refused it would contradict the statement; in that case the way is to reverse the installment in Accounts Payable/Receivable.

🗂 Tab: Approvals

The history of signatures, from the most recent submission to the oldest: Submission (the batch may have been sent more than once), Step ("2 - Director"), Approvers (who could sign), the step's Status — Pending, Approved, Returned or Canceled —, Signed by, Date and Reason.

This is where a return is recorded: the step is marked Returned, in red, with who returned it, when and the reason; the remaining steps are marked Canceled. The line is not erased when the batch goes back to draft, and the next submission comes in as a new cycle.

The splitting warning

At the top of the tab — and in the submission confirmation — a red warning may appear: "Attention: suppliers in this batch are also in other batches from the last 7 days", listing each supplier, the number and status of the other batch and its amount there. When the sum of the two would fall into a higher approval range, the warning adds: "If it were a single batch (R$ 118,000.00), it would fall into the range 'Above R$ 100k'."

It is a guard against splitting — dividing a large payment into small batches to fall into a range that requires fewer signatures. The warning is for whoever builds and whoever approves, and it does not block anything: there are legitimate reasons for the same supplier to appear twice in a week. In that case the submission button reads Send anyway.

✍️ Send, approve and return

1. Send for approval — upCampo adds up the batch, looks for the active range in the approval rules that covers that total and copies its steps to the batch. Missing range, missing step or missing approver in a step? The batch stays in draft and the message says what to set up.
2. Approve — signs the current step. If it was the last one, the batch becomes Approved; if not, the response is "Step approved. The batch moves on to the next step."
3. Return — at any step, with a required reason, the batch goes back to draft. The dialog's help text warns what happens next: "Whoever built it corrects and resends it, and approval starts over from the first step."
4. Back to draft — unlocks the batch (in approval or already approved) so you can change the installments. It erases the final signature and ends the cycle: whoever approved did not approve this, they approved the batch as it was.

Three checks apply at signing time, each with its own message: only an approver of the current step can sign; whoever created or sent the batch cannot approve it; and whoever has already signed one step cannot sign another in the same submission. They are detailed in the Approval rules article.

Approve and settle from the list

You don't need to open the batch to sign. In the list's Actions column, each line has Approve and Settle batch, enabled only when the action is possible for you on that batch — Approve shows as active only on batches where you can sign the current step right now. With the Awaiting my approval filter, the list shows only those.

Whoever approves from the list has not seen the installments, so the click first opens a confirmation with the batch's items and the total: "Check the installments before signing. Approving signs the current step: if it was the last one, the batch becomes approved and can be settled." No one signs what they haven't read.

🔐 Required approval to settle

By default, the payment batch is an extra path: anyone who wants to can still settle installments directly in Accounts Payable/Receivable. If you want approval to really count, turn on the option Require approval to settle in File > Company/Crop Settings, in the Financial block. The field's help text sums it up: "When on, no settlement happens outside an approved payment batch - on any screen. Requires approval rules to be set up."

With it on, any attempt to pay an account payable that is not in an approved batch is refused with "This company requires approval to settle: the installment must be in an approved payment batch." — no matter which screen the settlement came from. It is all or nothing on purpose: a single path around it would mean the approval controls nothing.

Since October 5, 2026, the rule applies only to accounts payable. Approval exists to authorize money going out, and the batch only accepts payable documents — so receivables are received normally in Accounts Payable/Receivable, whether the option is on or not.

Building the batch from the payment window

With the option on, a batch can also be started in Accounts Payable/Receivable. The Payment & Receipt window for an account payable does not offer Make payment/receipt: it says the payment goes out through an approved batch and shows the Add to batch button. In the Payment batch field you choose a batch in Draft or New batch — which asks for the bank account and the description — and the checked installments go into it. From then on the path is this screen's:

1. add to batch;
2. send for approval;
3. approve;
4. pay — by settling the batch or by reading the bank's return file.

If the installment is already in a batch, the window tells you which batch and its status, and the Open batch button brings up this screen with that batch selected. That installment is settled through the batch even after the batch is approved: that is how the batch knows what was paid, and the bank's return file does not pay again what was already paid outside it.

📤 Export payment file (Banco Inter CNAB 240)

Export payment file generates the file you upload to the business online banking so the bank pays the whole batch at once, instead of entering one payment at a time. The button's help text defines what it is: "Generates the batch's CNAB 240 file, in the Banco Inter layout, to import into business online banking."

Generating pays nothing. The bank pays, after you upload the file there; the settlement in the system is still a step of yours, through the return file, the statement or the settle button. The button works on an Approved batch — the signature is what authorizes sending money — and on a batch that already has Payment file generated, because re-exporting is normal (the file gets lost, the bank rejects the upload, someone needs to upload it again). Once sent or paid, no: from then on what's left is reading the return file.

Only pending installments go into the file: a rejected one is no longer money going out, and a paid one has already gone out. PIX and TED go out in the same file, in separate batches.

The "How it will be paid" column

In the Installments tab, the How it will be paid column answers, before anyone clicks export, which way each payment will go and where the bank details came from:

• PIX by key — the payee has a PIX key with its type filled in. It is what upCampo chooses whenever it can: it arrives instantly, costs nothing and does not depend on business days.
• Wire transfer (TED) — no PIX key, but bank, branch and account.
• PIX by bank details — the form that requires the ISPB of the payee's bank.
• No payment details, in red — the record has neither a PIX key nor an account.

In parentheses comes the origin of the details: Entity or Address. When money lands in the wrong place, the first question is "where did those details come from?", and the column answers without opening the record.

If anything is missing, no file is generated

When something is missing, upCampo opens the list: "The payment file was not generated. Fix what is missing and generate it again", with one line per issue and the supplier's name on each. Fix the record and click export again.

What the supplier record needs to have, in the Payment details tab:

In addition, the payee needs a complete CPF or CNPJ in the record, and the batch's bank account needs an account number and check digit — Inter's manual explicitly does not accept a blank check digit — and the company needs a CNPJ.

The file and the payment date

• Do not rename the file: it comes out as CI240_001_NNNNNN.REM, and online banking checks the name on upload. The screen warns: "Download the file and import it into Inter's business online banking. Do not rename it: the bank checks the name on upload."
• Re-exporting reuses the payment file number and the "your number" of each installment. There are two different reasons: the bank refuses a repeated payment file number on the same day, and changing the "your number" would make the previous file's response find the wrong installment. The file comes out the same — it is not a new payment.
• The payment date is not the due date when that date has already passed. The bank does not accept a date in the past, and overdue installments are exactly what goes into a batch most often: a past due date becomes today, which is when you are sending the file.
• TED does not go out on weekends, so a TED's date moves to Monday. PIX goes out any day.

📥 Import bank return file (.RET)

It is the other half of the payment file. The bank sends back a .RET file saying, payment by payment, what it did with each order — and this screen applies that response: what the bank carried out is settled with the actual date and actual amount it reported, and what it refused is marked as Rejected, with the occurrence in text, becoming free again for another batch.

The matching is exact: each line in the file finds its installment by the "your number" the payment file recorded. There is no tolerance, no leeway in days and no possible tie — if the "your number" does not belong to any installment in this batch, that line is not from this batch. That is why the button only exists after the payment file has been generated: in a batch that is only approved, no installment has a "your number", and the file would find an owner for nothing.

The screen shows what it will do before doing it — "N installment(s) to settle and N to reject", plus the lines in the file that are not from this batch and those already applied — and each installment with what the bank said, the actual date it was carried out and the amount actually paid.

The confusing cases

Settlement uses the actual date of each line, not today's: installments carried out on different dates are settled separately. And a closed period still blocks — no bank return file justifies changing a closed month.

🔍 Reconcile the batch against the statement

Reconcile bank return file is the other path, and it answers a different question. It imports the statement the bank sent back and checks the batch's items against the lines in the file, matching by amount and date, with tolerance: what matched can be settled with the statement's date, and what did not match can be rejected with a reason.

The difference between the two is how you know whose each line is: the return file says what the bank did with the order and matches exactly, by the "your number"; the statement proves what left the account and matches approximately. Neither replaces the other — and reconciliation is the path for those who paid outside the CNAB file, or who want proof that the money went out.

The dialog is closed on purpose: only the installments of this batch against the lines of this file. It does not create entries, does not look for installments of another entity, does not offer candidates. If you need the rest, there is the full Bank reconciliation screen, right next to it. It works from an approved batch on, even an already paid one — it is normal to check the bank's file after a partial settlement.

Two things happen along with the settlement, and they prevent problems later:

• The file's lines are saved in bank reconciliation: those that matched, already reconciled with the installment they paid, and the rest as pending, to be resolved in Bank reconciliation — a fee, a tax, a payment outside the batch. Without this, anyone importing the same statement later would see those lines pending with no candidate, and a click on "Create document" would create a new expense for a cost that was already in the results.
• The file's account must be the batch's account. If it is a different one, the screen warns in red and requires explicit confirmation: settling that way would record one bank's activity inside another account.

💰 Settle batch

Settle batch is the manual path: it pays off all of the batch's pending installments at once. It only works on an Approved batch — after exporting the payment file, the way to pay is Reconcile bank return file or Import bank return file, which also settle.

The dialog asks for the Bank Account (the batch's comes pre-filled), Payment date (today), Payment method — Cash, Transfer, Credit card, Boleto, PIX or Check, with Transfer selected — and Notes, showing how many installments and how much will be paid. The help text says what it is: "Settlement uses the same path as Accounts Payable/Receivable: each installment is paid off once, moving the balance and the statement of the chosen account."

There is no batch-specific settlement: it is the same settlement as the Accounts Payable/Receivable screen, with the same rules and the same effects on the account balance. After it, the installments that were paid off become Paid in the batch, and the batch becomes Paid when none is left pending — otherwise the response is "Batch partially paid. The installments that were not paid off remain pending in the batch."

The financial close blocks settlement

If any pending installment in the batch is due within a closed period, the Settle batch button starts out disabled, and the explanation appears on hover: "3 installment(s) in the batch are due in a closed period and would be refused at settlement.", with the date through which finances are closed.

The number matters: it lets you go after the installments in question instead of guessing. Inside the settlement dialog the count is redone each time the payment date changes — the chosen date can also fall inside the closed period.

Without the warning, the batch would come back "partially settled" with no explanation: what really blocks it is the close's lock, which applies to the whole system, and it refuses the line midway. The two ways forward are: settle with a date after the close, when that is correct, or ask whoever is accountable for the finances to reopen the period.

⚠️ What is not included yet

So you don't find out in the rush of paying:

• Boletos (bank payment slips) and taxes with a barcode are not included in the payment file or the return file. Today's file carries PIX and TED. Supplier boletos and tax slips are still paid at the bank, one by one, and settled through Settle batch, Bank reconciliation or in Accounts Payable/Receivable. PIX by QR code isn't either.
• The payment file is only generated in the Banco Inter (077) layout. A batch whose bank account is at another bank does not generate a file — the issue says which bank it is. The rest of the screen (approval, settlement, reconciliation) works with any bank.
• A return file from another bank is read with caution. The FEBRABAN standard positions are the same, but the table of occurrence codes is specific to each bank: a code that is not recognized appears raw, and upCampo warns that the file is from another bank.
• Bank holidays are not handled, as mentioned above.
• Only installments payable go into a batch. There is no receivables batch, and old documents with a type outside today's standard do not appear in the selection.

❓ Frequently asked questions