# Recurring invoice vs recurring payment: what changes?

Does a recurring invoice collect payment automatically? Compare invoicing and recurring payments with a monthly-service example and a failure-handling checklist.

- Author: Komashi Team
- URL: https://komashi.com/blog/en/2026/10/21/recurring-invoices-vs-payments/
- Published: 2026-10-21
- Updated: 2026-10-22
- Language: en

## At a glance

Recurring invoicing creates billing documents; recurring payments initiate collection. You can connect them, but their outcomes and errors need separate tracking. Subscription periods and service access also need their own rules.

A recurring invoice creates a billing document for a repeated charge. Collecting the payment is a separate task: your setup may charge an authorised payment method automatically or ask the customer to pay each invoice. Before launching a monthly service, establish which outcome each system records.

An invoice can exist while payment is outstanding, and a payment can succeed while invoice generation fails. The example and failure table below show how to keep invoicing, collection, and the customer's service period traceable.

## What is the difference between recurring invoices and recurring payments?

**Recurring invoicing** creates a new billing document on a schedule or in response to a business event. **Recurring payments** initiate another collection under the customer's authorization and the payment method's requirements. One concerns the document; the other concerns the transaction.

| Question | Invoice generation | Payment collection | Subscription management |
| --- | --- | --- | --- |
| What does it handle? | Creating the billing document | Collecting money and tracking the result | The plan, service period, and renewal rules |
| What result can you inspect? | Invoice number, document, and issuance status | Transaction identifier and payment status | Subscription and service status |
| What does it not prove on its own? | That the money arrived | That an invoice was issued | That every connected operation succeeded |

You can combine these functions. A recurring invoice may also have automatic collection: [Stripe's collection-method documentation](https://docs.stripe.com/billing/collection-method), for example, distinguishes automatic charging from manual payment for subscriptions. Check which collection method your setup actually uses.

Also, *subscription billing* often describes a broader process than generating an invoice. When comparing products, ask what their use of “billing” includes.

## What triggers the recurring invoice?

Write down the event that creates the document. A monthly schedule and a successful-payment event are different triggers. They require different checks: one follows the calendar, while the other waits for the collection result. Confirm which sequence your payment and invoicing integrations support.

Komashi documents an invoicing connection that follows successful payment. Treat that as a specific workflow when comparing it with a requirement to issue documents on a fixed date regardless of payment.

## Which part do you need to automate?

Start by separating three common requirements:

- **“Send a new invoice every month.”** This is a document-generation requirement. You still need to decide how the customer pays and how you track the result.
- **“Let the customer pay without starting a fresh checkout every month.”** This requires a supported recurring collection method and the appropriate authorization.
- **“Give the right customer access for the right period.”** This requires subscription and service rules: when a period starts, what renews, and what happens after a failed payment.

Invoice automation and reconciliation may have separate integrations, too. As a Hungarian example, [Számlázz.hu's Számla Agent](https://tudastar.szamlazz.hu/gyik/szamla-agent-automatikus-szamlazas-koltsege) lets an external system request billing documents. Its [autokassza feature](https://tudastar.szamlazz.hu/gyik/hogyan-mukodik-az-autokassza) can match incoming bank transfers to invoices. Matching a transfer records a payment that has already happened.

## Worked example: renewing a monthly service

Suppose you sell a service for HUF 12,000 per month, with a new service period starting on the 10th. This is an illustrative workflow, not a Komashi plan price or a customer result. The same design questions apply with another currency or amount.

One possible sequence is:

1. The service system determines that the next period's charge is due.
2. The payment integration initiates the authorized collection.
3. The system checks and records the actual payment result.
4. The invoicing task associated with the successful payment creates the document.
5. Subscription and access status are updated according to the service rules you defined.

This example assumes invoicing after payment. Other workflows issue a document or payment request first. Confirm your own invoicing obligations and timing with your accountant.

In this example, you need three traceable outcomes: the payment, the document, and the service period's status. A single “renewal completed” message will not tell you which part still needs attention.

## What if only part of the renewal succeeds?

Use the following table as a planning aid. Adapt the actions to your chosen system and service terms.

| Payment status | Invoice status | Next action |
| --- | --- | --- |
| Successful | Issued | Check the customer, period, and service status match the intended renewal. |
| Successful | Failed or missing | Investigate invoice generation; an invoice failure alone is not a reason to charge again. |
| Failed | No document | Handle the payment failure and apply your defined access policy. |
| Not received yet | Issued | Track the outstanding payment; the document does not prove settlement. |

Include unknown outcomes in your process. If a response arrives late, look up the original transaction before starting another attempt. Otherwise, you can create two payment attempts for the same service period.

This is also why “automatic” needs a clear scope. A working invoice schedule does not tell you how an unsuccessful collection will be handled. A payment result does not tell you whether a customer should keep access during a grace period. Those decisions need an owner and an explicit rule.

## How does Komashi fit into this setup?

Komashi has separate configuration areas for [payment providers](https://komashi.com/docs/provider/Settings/08payment-providers/) and [invoicing providers](https://komashi.com/docs/provider/Settings/09invoicing-providers/). Its payment documentation describes the customer paying the provider through the payment service; Komashi is not part of that money flow. Choose a method that fits your region and workflow. A method appearing in the list does not establish that it supports automatic recurring collection.

The invoicing guide explains how to connect your own invoicing provider. With the integration enabled, successful payments are followed by automatic invoice generation. The integration is optional: you can issue invoices manually outside Komashi, in which case creating the document remains your responsibility.

The [Subscriptions view](https://komashi.com/docs/provider/subscriptions/) lets you inspect the customer, plan, status, and recurring price. That gives you a subscription-level view alongside the payment and invoice records.

## A checklist before your first live customer

Use your providers' test environments or documented testing procedures to check that:

- The price, period, and renewal terms are clear.
- Your chosen payment method supports the intended renewal flow.
- The required customer authorization is captured.
- You can inspect payment and invoice-generation outcomes separately.
- You have defined what happens after a failed payment or an unknown result.
- Someone owns invoice errors, with a process that avoids charging again unnecessarily.
- Customers know where to find their subscription and get help.

For each scenario, write down the expected outcome before trying it. A useful acceptance check is specific: “the original payment remains successful and the invoice task is investigated” is clearer than “the billing error is handled.” Keep the sample transaction identifier and period together so you can follow the same renewal across systems.

**Setting this up with Komashi?** Start with [choosing a payment provider](https://komashi.com/docs/provider/Settings/08payment-providers/), then review the [invoicing connection](https://komashi.com/docs/provider/Settings/09invoicing-providers/) separately. You will have a clearer view of which system owns each result before customers depend on the workflow.

## Frequently asked questions

### Does a recurring invoice automatically collect payment?

Issuing an invoice does not itself establish that money was collected. Automatic charging needs a suitable payment connection and customer authorization. Some systems combine invoicing and collection; check your actual configuration.

### Do recurring payments include automatic invoicing?

That depends on the system and integration. Komashi documents a separate, optional invoicing connection that generates invoices after successful payments. Manual invoicing outside Komashi is also an option.

### What if a payment succeeds but the invoice is missing?

Check the payment result and original transaction, then investigate invoice generation using the system’s documented procedure. A missing invoice alone is not a reason to charge the customer again.

## Sources

- [Stripe — Billing collection methods](https://docs.stripe.com/billing/collection-method)
- [Komashi — Payment Providers](https://komashi.com/docs/provider/Settings/08payment-providers/)
- [Komashi — Invoicing Provider](https://komashi.com/docs/provider/Settings/09invoicing-providers/)
- [Komashi — Subscriptions](https://komashi.com/docs/provider/subscriptions/)
- [Számlázz.hu — Számla Agent](https://tudastar.szamlazz.hu/gyik/szamla-agent-automatikus-szamlazas-koltsege)
- [Számlázz.hu — Autokassza](https://tudastar.szamlazz.hu/gyik/hogyan-mukodik-az-autokassza)