Online Invoice Payment Portal

The problem

Your customer wants to pay you. They open the emailed PDF, find no way to pay from it, and put it in a pile. Two weeks later somebody in your credit control team phones them. That phone call is the product you are currently selling, and it is expensive.

Meanwhile the other half of the cost sits inside SAP Business One. Payments arrive as bank transfers with a reference that reads INV PAYMENT and an amount that covers three invoices and part of a fourth. Somebody manually creates the Incoming Payment, hunts for the right open A/R Invoices, applies the amounts, and hopes the remainder was a short-pay rather than a keying error. Every one of those is a chance to misapply cash, and misapplied cash produces a dunning letter to a customer who already paid.

Native SAP Business One has no customer-facing surface at all. There is no portal, no payment link, no self-service statement. The gap between invoice issued and cash applied is filled entirely by human effort, and that gap is your days sales outstanding.

What ECOSIRE builds

We build a per-tenant portal that sits in front of your SAP Business One company database and closes that loop.

The customer-facing portal

A branded web portal where a customer signs in and sees exactly what SAP B1 knows: their open A/R Invoices, amounts, due dates, and what is overdue. Data is read live through the Service Layer (Invoices, BusinessPartners) — there is no shadow copy of your ledger drifting out of date. Customers can view or download the invoice document, including the Crystal Report layout you already use, so the portal shows the same document your finance team sees.

Access is scoped per Business Partner. A customer sees their own account and nothing else, with contact-level logins mapped to the BP so multiple people at the same customer can be granted access independently.

Paying

The customer selects one invoice, several invoices, or pays the full outstanding balance, and pays by card or wallet through your chosen payment provider. Partial payment is supported where you allow it, configurable per Business Partner or per payment terms group. Every emailed invoice can carry a secure pay-now link that takes the customer straight to that document, already selected — no login hunt, no reference to copy.

The part that actually saves the money

On a confirmed payment, the add-on service creates the Incoming Payment in SAP Business One through the Service Layer and applies it against the specific invoices the customer selected. Not a lump credit on the account. Not a suspense posting for somebody to sort out on Monday. The correct invoice rows, with the correct amounts, producing the correct Journal Entry against the configured bank or clearing G/L account, with payment provider fees posted to their own account where you want them separated.

Because the customer chose the invoices, the allocation is unambiguous. The reconciliation problem disappears at source rather than being solved after the fact.

Idempotency and reconciliation

Payment providers retry webhooks, and browsers get refreshed at exactly the wrong moment. Every payment attempt is recorded on a UDO ledger carrying the provider reference, the selected invoice keys, the amount, the state and the resulting SAP B1 payment document number. A provider reference that has already produced an Incoming Payment can never produce a second one. A payment that succeeded at the provider but failed to post in SAP B1 lands in an exception queue with the provider reference intact, so it is visible and recoverable rather than lost.

A reconciliation Crystal Report shows portal payments against posted Incoming Payments and flags any that do not match.

Statements and visibility

Customers get a live account statement — open items, aging, recent payments and downloadable receipts. Your own team gets the same view internally, which removes a large share of the "can you send me a copy of that invoice" emails that currently interrupt the finance day.

Controls

Credit-hold Business Partners can be excluded or shown read-only. Minimum and maximum payment amounts are configurable. Overpayment behaviour is a deliberate configured choice, not an accident. Where you want a human gate on unusual amounts, the add-on can route the posting through standard approval procedures before the Incoming Payment is created.

Who this is for

B2B companies running SAP Business One with a meaningful book of open A/R and a credit control function that spends its week chasing rather than analysing. It suits distributors, manufacturers, professional services firms and anyone invoicing a long tail of customers where the cost per collection call is high relative to the invoice value.

If you have twelve customers who all pay by standing order on the same day, this is not your bottleneck.

Technical framing

Built as a SAP Business One integration and portal using the Service Layer (REST) for reading Business Partners and open A/R Invoices and for creating Incoming Payments, the DI API where a transaction requires it, and UDO/UDF/UDT for the payment ledger, portal access mapping and configuration. Compatible with SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or cloud-hosted. The portal is delivered per tenant against your company database. Payment provider credentials, G/L account mapping, fee treatment, partial-payment rules and access policy live in configuration rather than in code.

How delivery works

Nothing is pre-built and there is no instant download. Each portal is built for your company database, your payment provider and your posting rules.

1. Scoping call. We walk your A/R process, payment terms, credit-hold policy, which payment provider you use or want, your G/L mapping for bank and fees, and how you want partial payments and overpayments handled. 2. Fixed quote. Written scope, fixed price, no hourly drift. 3. Build. Typical lead time is one working week from signed scope, depending on provider integration and branding scope. 4. Install into your test company. Installed against the test database with your provider in test mode. We run real scenarios end to end: a full payment, a multi-invoice payment, a partial payment, a duplicate webhook and a deliberate posting failure — so you see the recovery path, not just the happy path. 5. Install into production. After test sign-off, installed against the production company database and switched to live provider credentials, with a supervised first payment window. 6. Support. A support window follows go-live for defect fixes and adjustments arising from real customer behaviour.

You own the deployment. Source is delivered with it, documented, and maintainable by your own team or your SAP B1 partner.