How to reconcile course payments with your bank statement

Students paid UAH 30,000, but the school's account received UAH 26,400. Before you search for a missing payment, check what exactly these figures compare. The first may include all successful payments for the month, while the second already accounts for fees, refunds, and payouts that haven't reached the bank yet.

For a school with subscriptions and installment plans, reconciliation should answer specific questions: who paid and for what, which funds have already been received, what is still due to be paid out, and where each discrepancy came from. Below, we'll walk through a working procedure and a numerical example. It will help you prepare verified data for sole proprietor (FOP) income records, but on its own it doesn't determine the tax amount or the date of each transaction.

Why totals differ across accounts

Imagine a course for UAH 9,000 with three payments of UAH 3,000. After the first successful payment, the school has an order for UAH 9,000, a received payment of UAH 3,000, and another UAH 6,000 on the schedule. If the payment service withheld a hypothetical 2% fee, UAH 2,940 will reach the bank for this payment. All these amounts can be correct, but each describes a different event.

So compare the data step by step:

• The order and schedule show how much the student needs to pay and when.

• Transactions show payment attempts, successful payments, and refunds.

• The payout report explains which transactions the service combined into a bank transfer and what it withheld.

• The bank statement confirms the funds were credited to the account.

• Income records contain amounts and dates determined by tax rules and documents.

On Kwiga, one order can have several transactions, for example due to a subscription, payment in installments, or a failed payment attempt. The "Transactions" report also distinguishes between the transaction creation date and the operation date. So the number of rows in the report doesn't equal the number of paid orders. Field details are described in the Kwiga help article on transactions.

Prepare sources using the same rules

For your first reconciliation, take a completed month. Save as separate files the platform's transaction export, the payment service report with fees and payouts, bank statements, and your current income table. If needed, add the register of fiscal receipts and refund documents.

Make sure you've covered all business accounts and all connected payment acceptance accounts. Reconcile direct IBAN transfers separately: they may appear in the statement but not in the acquiring report. If the school operates through several sole proprietors, first split transactions by the recipient of funds.

Record the currency, time zone, period boundaries, and the date field each report is based on. For payments at the turn of the month, you'll also need payouts from the beginning of the next month. Don't move the payment itself to the new period because of this: keep both dates and explain how they're linked.

Leave the source files unchanged. Make copies to work with, and enter corrections in the reconciliation table with a brief reason. This helps you retrace the check if a transaction's status changes later.

Build reconciliation around the payment ID

One student may pay the same amount every month, and several students may buy the same plan on the same day. So amount, date, and name are fine for searching, but not enough to merge records automatically.

Start with the payment service's transaction ID. If there are several accounts, add the service name and account ID to it. Separately store the order number and the transaction number on the learning platform: they don't necessarily match the provider's ID.

Your working table needs these groups of fields:

• Sale link: order, platform transaction, provider transaction, product, installment number, or subscription period.

• Event: payment, refund, or other operation; its status, amount, currency, and date.

• Payout: fee, other confirmed deductions, payout ID, amount, and bank credit date.

• Control: reconciliation result, reason for discrepancy, link to supporting document, person responsible, and recheck date.

Record refunds as a separate event with their own ID and a link to the original payment. Don't replace the sale amount with the balance after the refund: this loses the transaction history.

Don't try to fit everything into one row. If one bank payout combines dozens of transactions, it's easier to have a separate payouts sheet and a "transaction → payout" mapping table. Count the bank credit amount once per payout rather than repeating it for each payment.

Reconcile payments and explain each payout

First, match successful platform payments with provider transactions. Keep failed attempts and pending payments in a separate selection. Course access status or a manually set "paid" mark must be confirmed by a monetary transaction.

Then check the provider's payouts against the bank statement. For each payout, rebuild the calculation: the payments included in it minus fees, minus refunds and other deductions, plus any separate adjustments. Use the actual report rows, not an approximate percentage of sales.

When the service shows a balance of funds not yet paid out, you can structure the monthly check like this:

Opening balance + successful payments − refunds − fees − other deductions + adjustments − payouts to bank = closing balance.

Each term must match its definition in your provider's report. For example, if the reserve is already included in the unpaid balance, don't subtract it again. Reconcile currencies separately and confirm conversions with the service's report.

Monthly reconciliation example

A hypothetical school accepts only hryvnia payments through one service. At the start of the month, there's no unpaid balance. During the month, the following payments went through successfully:

Two failed charge attempts are not included in these 15 payments. The UAH 6,000 that students are scheduled to pay next month is also not added to payments received.

According to the provider, the school refunded UAH 1,000 from one successful payment this month. Fees came to UAH 600. At the end of the month, UAH 2,000 remained unpaid out. For this example, assume there are no other deductions, and the fees are already fully accounted for and were not reimbursed on the refund. These are example conditions, not the pricing of a specific service.

If the statement shows UAH 26,400, the difference from sales is explained. If it shows UAH 25,400, UAH 1,000 remains unexplained. You can't automatically call it a fee or a refund: you need the matching report line or confirmation from the provider.

When the remaining UAH 2,000 reaches the account next month, link it to the original transactions. This settles the balance pending payout. It doesn't create a new sale in the management report. Check the tax date separately.

What to check for subscriptions and installment payments

For a subscription, keep the period the charge covers and all payment attempts. A failed charge followed by a successful retry should result in one successful payment. If both operations succeeded, check for a possible double charge. Don't delete one just because the amounts match.

With its own installment plan, the school tracks each installment: the scheduled date, the actual payment, and the unpaid balance. The total course price isn't duplicated in every month.

Treat bank installment payments separately, for example the seller payout model at monobank. Depending on the specific product's terms, the bank may transfer the full amount to the seller at once, while the student repays the bank. In that case, the school reconciles the payout received and the fees under the agreement, not the student's future installments as its own income. The school's own installment plan and a bank loan may look similar to the buyer but involve different cash flows for the seller.

How to resolve common discrepancies

Duplicate import. The same transaction ID from the same account appears twice. Compare the sources and keep one record in the total. If the rows reflect a status change, keep the history rather than two separate payments.

The payment is at the provider but not on the platform. Match orders and IDs, and check for a confirmation delay or a sale outside the platform. Don't create another payment instead of finding the cause.

The refund is approved but not yet completed. A student's request or a button click doesn't confirm the money has actually moved. Keep the status "pending", and once it's completed, add the amount, date, and confirmation.

The amount after a refund doesn't match what you expected. Check whether the provider returned the fee, charged a separate fee, and which payout includes the transaction. Handle forced refunds through payment disputes separately as well.

The total matches, but a row doesn't. A missing UAH 1,000 can be accidentally offset by an extra UAH 1,000. So in addition to checking the total, match IDs and the number of successful transactions.

How to transfer the result to sole proprietor (FOP) income records

After reconciliation, you can explain where the money went. Next, for each transaction, determine the income amount and date based on its documents and current tax rules. Don't automatically transfer either the order total or the net payouts after fees to the income table.

For card payments via bank or online acquiring with a fiscal receipt issued, the State Tax Service (STS) clarifies that income includes the full revenue together with the bank fee, and the date of income is the date on the fiscal receipt. So the rule "always take the amount and date from the bank statement" is incorrect in this case. Source: STS clarification on sole proprietor income with acquiring.

For refunds, keep the grounds, a document confirming the actual refund, and the link to the original payment. Subparagraph 5 of paragraph 292.11 of the Tax Code of Ukraine provides that the relevant refunded funds are not included in income under certain conditions. However, the periods of receipt and refund matter. The STS clarification on refunding an advance after a contract was terminated in a different tax period refers to amending previously filed returns. So simply subtracting the amount in the current quarter may be wrong. Source: how to record a refund according to the STS clarification.

Agree with your accountant on the rules for dates, fees, refunds, and fiscalization for your payment setup. This is especially important for transactions at the turn of a quarter, foreign payment services, and non-standard contracts. The example above explains the UAH 26,400 in the bank, but it is not a ready-made income calculation for the tax return. Tax references were checked on November 5, 2026.

When a month counts as reconciled

Finish the check when every successful payment has a match or a recorded reason for the discrepancy, every bank payout is explained by its transactions, and the balance due is confirmed by a report. For open issues, specify who is responsible and the date of the next check. "Probably a fee" does not close a discrepancy.

Before carrying over the result, check the spreadsheet itself: does the total cover new rows, are amounts stored as numbers, and was a repeated import counted twice? For this, you can use 10 checks for a sole proprietor income spreadsheet in Google Sheets by MYFOP UA.

Start with one completed month and one payment service. Once you can show the payments, fees, refunds, and balance for each payout, the same process is easy to repeat. Then the school owner sees not just the total sales figure, but also which money is already available, which is still expected, and which transactions need attention.