Automatic Payment Matching in SuperFaktúra: A Practical Guide

Automatic payment matching in SuperFaktúra requires a reliable source of bank transactions, explicit rules for identifying invoices, and a review process for ambiguous payments. Check the features available in your account before building an integration, and record payments automatically only when the match is unambiguous. Every write must also prevent the same transaction from creating a second payment record.

What does automatic payment matching actually do?

Automatic payment matching is the process of assigning an incoming bank transaction to an invoice using predefined rules. SuperFaktúra is an invoicing application used by businesses in Slovakia and the Czech Republic; the objective here is to record received payments against the correct invoices.

Consider a wholesaler whose customers pay by bank transfer. An administrator opens the bank account, finds the payment reference, compares the amount, and records the payment against an invoice. Most straightforward transactions require the same checks repeatedly.

Automation performs those checks and leaves uncertain cases for a person. Correct payment records can also support downstream processes such as shipping approvals or payment reminders, provided those processes use verified invoice balances.

This approach makes sense when bank payments arrive regularly and follow consistent rules. For a business handling only a few invoices each month, an available built-in feature or controlled import may cost less than a separate integration.

Payment matching is not full accounting reconciliation. It establishes the relationship between money received and an outstanding invoice; it does not validate every bank fee, tax treatment, or accounting entry.

What should you verify in SuperFaktúra and your bank?

Verify how your SuperFaktúra account can receive transaction data and record payments before choosing an implementation. We have not verified current supported banks, subscription requirements, or interface capabilities here, so this guide does not promise a particular connector or provide menu-specific instructions.

Prepare the following information:

• Transaction access: an available bank connection, authorized API access, or a supported export and import process.
• Bank fields: a stable transaction identifier, account, amount, currency, payment reference, and relevant dates.
• Invoice fields: the internal invoice identifier, payment reference, currency, total, and outstanding balance.
• Write capabilities: recording payments, handling partial payments, correcting mistakes, and checking the result.
• Operating conditions: synchronization frequency, access permissions, interface limits, and the person responsible for exceptions.

An API is an interface that lets applications exchange data without manual re-entry. Having an API does not necessarily mean an application supports every operation your process needs.

Slovak transfers often use a “variable symbol,” a numeric payment reference used to identify the related invoice or obligation. Prefer a dedicated reference field when the bank supplies one. Extracting numbers from a free-text message needs stricter rules to avoid confusing an order number with an invoice reference.

Agree on reference normalization before launch. Removing spaces may be appropriate, but stripping leading zeros can change an identifier. Keep the original bank value so reviewers can inspect it.

How should a safe matching process work?

A safe process validates the transaction and invoice before recording anything, then checks that the write succeeded. The steps below describe a recommended design, not verified behavior of a particular SuperFaktúra feature.

1. Retrieve a booked incoming transaction. Do not treat a pending bank operation as confirmed payment. Store the source account and transaction identifier.
2. Check previous processing. A transaction already recorded must not generate another payment entry.
3. Find the invoice by reference. Continue automatically only when the reference identifies one eligible invoice in the correct company and currency.
4. Compare the amount with the outstanding balance. An exact match can proceed. A difference needs an approved rule or human review.
5. Record the payment through a supported operation. Include the amount, appropriate date, and transaction link according to system capabilities and the company’s accounting policy.
6. Verify the result. Check the updated invoice balance and log success, failure, or the reason for review.

For an illustrative example, a wholesaler receives €480 with a reference identifying one open invoice with €480 outstanding. If the currency and remaining checks agree, the system can assign the payment automatically.

If only €300 arrives, the system must not mark that invoice as fully paid. It should record a partial payment only if the integration supports it and the business has approved that behavior. Otherwise, it should send the case for review.

This is the practical boundary of business process automation: remove repeated data entry without inventing decisions that the available evidence cannot support.

Should you use an available feature, Make.com, or custom code?

Choose the least expensive option that safely handles your actual payment rules. Start with the features available in your account, then assess Make.com, n8n, or a custom application if there is a specific gap.

Option	When to consider it	What to verify	Ongoing responsibility
Available SuperFaktúra feature	It covers your bank and routine payments	Account support, matching rules, exceptions, and subscription cost	Configuration and result checks
Make.com or n8n	Several systems must exchange data and expose the required operations	Transaction retrieval, payment writes, retries, and interface limits	Workflows, credentials, logs, and alerts
Custom application	Allocation rules or control requirements are more involved	API coverage, development scope, and maintenance ownership	Code, database, monitoring, and updates

This comparison does not confirm that any particular connector is available. A connector might retrieve invoices without supporting partial payment recording or reliable verification after a write.

A custom implementation could use Laravel + PostgreSQL for matching rules, processed-transaction records, and an exception queue. That technology choice cannot compensate for an operation missing from the bank or invoicing interface.

You do not need AI to compare a reference, currency, and amount. A deterministic rule produces the same result from the same inputs, making it easier to test, explain, and maintain.

How do you calculate savings and payback?

Calculate payback from work genuinely removed, after allowing for exception handling and operating costs. Invoice volume alone is not enough: the number of payments and their complexity determine the workload.

The following is an illustrative estimate using hypothetical inputs, not a LightWeb price or project result:

• Processing 200 payments at three minutes each takes 10 hours per month.
• If checks and exceptions take two hours after automation, the business frees eight hours.
• At an assumed labor value of €20 per hour, that capacity is worth €160 per month.
• With hypothetical running costs of €40 per month, the remaining benefit is €120.
• If setup cost €600, simple payback would be five months.

Replace every assumption with your own measurements and a scoped implementation quote. Actual cost depends on bank access, available features, account count, exception rules, testing, and maintenance.

Freed capacity is not automatically a cash saving. It creates a financial benefit when, for example, the business reduces overtime or handles additional work without another hire.

LightWeb’s Savings Map is a free 30-minute consultation that identifies three processes with the greatest savings potential. For payment matching, useful inputs include review time, exception frequency, and the effort required to correct errors.

Which mistakes can create incorrect payment records?

Loose matching rules and repeated writes are the main risks to control. When evidence is uncertain, the system should stop that assignment rather than choose the most plausible invoice.

An amount is not an identifier. Several customers may owe the same amount. The sender’s name may also differ from the invoiced customer, so use it as supporting evidence rather than the sole matching rule.

One transfer may cover several invoices. A combined payment needs a reliable allocation breakdown. Overpayments, foreign-currency payments, and amounts reduced by fees also need explicit handling; do not automatically write off differences.

A timeout does not prove a write failed. The receiving system may have recorded the payment before the response was lost. Check the result before retrying. Idempotency is the property that prevents repeated processing of the same input from creating an additional effect.

Two integrations can overlap. If an available feature and a custom workflow process the same account independently, both could record a payment. Establish one controlled write path for each source.

Corrections need an audit trail. Keep the original assignment, correction reason, and approving person. Limit credentials to the permissions required, protect secrets, and avoid copying sensitive bank information into general-purpose logs unnecessarily.

How can you launch without changing live invoice balances?

Start in a proposal-only mode and enable automatic recording only after reviewing the results. This exposes ambiguous rules without altering payment records.

1. Collect representative cases. Include partial payments, incorrect references, overpayments, combined transfers, and repeated imports. Assign an owner for exceptions.
2. Write the decision rules. Define when the system records a payment, suggests a match, or stops for review. Verify that both interfaces support the required actions.
3. Compare proposals with manual checks. Measure matching accuracy, exception volume, and review time. Test a connection failure during a write and retrieval of the same transaction twice.
4. Enable writes for proven cases only. Add failure alerts, a correction procedure, and a way to stop automatic recording before expanding the rules.

QA and test automation should specifically verify that retries do not create duplicate payments and that partial payments do not mark invoices as fully paid.

Do not measure success only by the number of automatic matches. Track incorrect assignments, exception resolution time, and missing transactions too. The objective is less manual work without losing control of outstanding customer balances.