Stripe Payments and Reconciliation

Stripe settles net. Your customers pay gross, Stripe deducts its processing fee, nets off refunds and disputes, and deposits a rolled-up amount into your bank account on its own schedule. SAP Business One, meanwhile, holds A/R Invoices at gross value and a bank account that needs to reconcile to a statement. Between the two sits a finance person with a CSV export, a spreadsheet, and a monthly ritual of matching a single payout line to dozens or hundreds of charges, then hand-posting the fee difference so the bank balances. It works, it is slow, and it is fragile in exactly the ways that matter: an unapplied payment ages a customer account that has actually paid, a fee posted in the wrong period distorts margin, and a chargeback nobody recorded shows up as an unexplained bank difference three weeks later.

This app is built to order. There is no download, no trial, and no pre-built binary. The value is in mapping your specific G/L determination, your payment means, your currencies and your invoicing pattern, so we scope it, quote a fixed price, then build and install into your company database. Typical lead time is two to four weeks.

What ECOSIRE builds

An integration service plus SAP Business One in-client objects. Posting goes through the SAP Business One Service Layer (OData/REST) so Incoming Payments and Journal Entries are created with the same validation a user gets in the client, and the DI API is used where the Service Layer has no equivalent. Every Stripe object we consume is first landed raw in a User-Defined Table keyed by the Stripe event and object identifier. That raw ledger is what makes the integration safe to rerun: a replayed webhook or a re-pulled day cannot double-post, and any figure in SAP B1 can be traced back to the exact source record.

Matching a charge to an invoice

The hard part of any payment integration is deciding which A/R Invoice a payment belongs to. We configure the matching chain with you at scoping, in priority order. Typically that means an invoice or order reference carried in Stripe metadata first, then a payment intent identifier stored on the SAP B1 document in a User-Defined Field, then an amount-and-customer heuristic within a tolerance you set. Anything that matches cleanly posts an Incoming Payment applied to the invoice, using the payment means and G/L clearing account you nominate. Anything that does not match is held in an exception queue with the candidate documents listed, so a human resolves it deliberately rather than the integration guessing.

Fees, refunds and disputes

Processing fees post as a Journal Entry to the fee expense account you nominate, in the period the charge belongs to, so cost of payment acceptance is visible in your P&L per period rather than as a lump at payout. Refunds raise an A/R Credit Memo where the refund corresponds to a returned sale, or post as an outgoing payment application where it is a straightforward reversal, and the treatment is chosen per scenario during scoping rather than forced into one shape. Disputes and chargebacks are recorded when raised, including the dispute fee, and reversed if resolved in your favour, so the bank difference is always explainable.

Payouts and bank reconciliation

Each payout is imported as a batch with its component charges, refunds, fees and adjustments enumerated. The connector posts the payout so that the amount hitting the bank G/L account equals the deposit line on your statement exactly, with the difference between gross receipts and net deposit already accounted for by the fee and refund postings. In practice that means the clearing account nets to zero for a completed payout, and your reconciliation is a single line match instead of an evening's work. Payouts that do not net to zero are reported, with the offending component listed.

Multi-currency

Where you charge in one currency and settle in another, the FX difference is posted to the realised gain or loss account you nominate, with the rate source recorded on the Journal Entry. Presentation currency, local currency and system currency behaviour is confirmed against your company setup during acceptance rather than assumed.

Who it is for

Companies running SAP Business One as the system of record that take card or wallet payments through Stripe, whether from a storefront, a hosted checkout, an invoice payment link or a subscription billing flow. It suits finance teams who currently reconcile payouts manually, businesses whose fee cost is material enough to want it visible per period, and any company where unapplied payments are ageing customer accounts that have in fact paid.

Technical approach and scope boundaries

The integration targets SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted. It requires a dedicated SAP B1 service user, network access to the Service Layer, and either inbound webhook delivery or scheduled polling of the Stripe API depending on your network posture. Both models are supported and we recommend one at scoping. No SAP standard tables are altered; we add UDFs, UDTs and UDOs. We are not a payment processor and we do not touch card data. Cardholder data never enters SAP Business One through this integration, only the tokenised references and amounts Stripe exposes. We make no certification or partnership claims about any payment provider.

How delivery works

It begins with a scoping call, usually ninety minutes, walking through your chart of accounts and G/L determination, payment means, how invoices are raised today, what identifiers you can put into Stripe metadata, your currencies, and how you want refunds and disputes treated. You receive a written scope and a fixed quote, and nothing is built until you approve it. Development runs against your structures where you can supply them. Installation goes into your test company database first and acceptance is run against a real historical payout cycle, which is the only honest way to prove the matching logic and the clearing account behaviour. After sign-off we install into production with a documented rollback for every object, at a time you choose.

After go-live

You get a support window covering defect fixes and configuration help, a runbook explaining the exception queue, the clearing account and how to reprocess, plus recorded training for the finance users who will live with it. Payment provider APIs and payout structures change, so maintenance beyond the included window is quoted as a separate support agreement rather than assumed.