Zum Inhalt springen
Zurück zur Übersicht
ERPNext

Accounting for Stripe Revenue in ERPNext with the Stripe Integration

A practical follow-up on handling Stripe revenue in ERPNext with the ERPNext Stripe integration, ALYF Banking, and the Bank Reconciliation Tool Beta.

Veröffentlicht am July 2, 2026

Titelbild zu Accounting for Stripe Revenue in ERPNext with the Stripe Integration

In 2023, I wrote about accounting for Stripe revenue in ERPNext with a mostly manual workflow: create a settlement account, post monthly revenue and VAT, enter Stripe fees, and clear payouts with Journal Entries.

That still describes the accounting idea correctly, but our workflow has changed. We now use our ERPNext Stripe integration together with ALYF Banking. Stripe imports the commercial side of the process, Banking imports the real bank side, and Bank Reconciliation Tool Beta becomes the place where both meet.

The key mental model is simple: Stripe is treated like its own bank account in ERPNext. Your real bank account is separate. A payout from Stripe to your bank is therefore not revenue; it is a transfer between two bank-like accounts.

What the Stripe integration does

The integration reads data from Stripe and creates the ERPNext records that should not be entered by hand:

  1. Stripe Customers become ERPNext Customers.
  2. Stripe products become ERPNext Items.
  3. Stripe invoices become ERPNext Sales Invoices.
  4. Stripe balance transactions become ERPNext Bank Transactions on a dedicated Stripe Bank Account.

This dedicated Stripe Bank Account should represent the Stripe balance, not the actual bank account that receives payouts. In ERPNext Stripe Settings, configure it as the Stripe Bank Account.

For restricted Stripe API keys, the integration only needs read access. In practice, that means read permissions for customers, products, prices, tax rates, invoices, payment intents, balance transactions, charges, refunds, and payouts. For live updates, subscribe the webhook to events such as customer.created, customer.updated, invoice.finalized, and charge.succeeded.

What Banking does

ALYF Banking imports the transactions from your real bank account into ERPNext. If Stripe pays out to your bank, Banking creates the real-bank Bank Transaction. If Stripe collects a negative balance by direct debit, Banking imports that withdrawal as well.

So for Stripe accounting, you usually see two worlds:

  • Stripe-side Bank Transactions, imported by the Stripe integration.
  • Real-bank Bank Transactions, imported by Banking.

The job is not to enter these transactions again. The job is to reconcile them correctly.

Daily reconciliation workflow

Open Bank Reconciliation Tool Beta and work through the Stripe Bank Account first.

When Stripe charges a customer, the Stripe-side Bank Transaction is a Deposit. Reconcile it against the corresponding Sales Invoice. The Stripe integration imports charge balance transactions using the gross amount. Stripe processing fees are imported separately, so the customer payment can clear the receivable without hiding the fee inside the payment.

When Stripe deducts fees, the Stripe-side Bank Transaction is a Withdrawal. Reconcile it against the corresponding Purchase Invoice from Stripe. Stripe often groups many small fee movements into later invoice documents, so this part is usually reviewed monthly rather than one transaction at a time.

The goal after reconciliation is that the Stripe Bank Account balance in ERPNext matches the actual Stripe balance.

Handling payouts

A Stripe payout is only a transfer. It moves money from the Stripe balance to your real bank account.

On the Stripe side, the payout appears as a Withdrawal. On the real bank side, Banking imports the incoming amount as a Deposit. Reconcile both sides through a Journal Entry using a cash-in-transit account:

  1. Reconcile the Stripe Bank Transaction against a Journal Entry that credits the Stripe bank GL account and debits cash in transit.
  2. Reconcile the real-bank Bank Transaction against the matching Journal Entry line that credits cash in transit and debits the real bank GL account.

This keeps the transfer visible and avoids treating payouts as revenue.

Handling negative Stripe balances

Sometimes Stripe does not pay out money to you. Instead, it collects a negative balance from your bank account, for example after refunds or fees.

In that case the signs are reversed:

  1. The Stripe-side Bank Transaction is a Deposit, because the Stripe balance is restored.
  2. The real-bank Bank Transaction is a Withdrawal, because money left your bank account.
  3. Reconcile both through cash in transit, just like a payout, but with the debit and credit sides reversed.

The accounting principle is the same: it is a transfer between the real bank and the Stripe balance.

Wrap up

Compared with the older manual workflow, the important change is that revenue and customer payments are no longer summarized manually at month end. The Stripe integration imports Sales Invoices and Stripe-side Bank Transactions; Banking imports the real bank movements; and Bank Reconciliation Tool Beta is used to connect the accounting documents.

There is still room for more automation, and that is where this workflow is heading next. Banking’s Bank Reconciliation Rule can likely be used to automatically book Stripe fees from matching Bank Transactions, but we have not tested that part yet. Later, those fee postings can be reconciled against Stripe’s monthly fee invoice with ERPNext’s Payment Reconciliation.

The next useful step would be to automatically reconcile successful Stripe payments with the imported Sales Invoices as well. That would turn most regular subscription payments into a review workflow instead of a booking workflow.

Uncollectible and cancelled Stripe invoices should also be automated eventually, but they are not handled yet and currently require manual attention.