Pay by Invoice

B2B customers often do not pay at the counter; they buy on account and settle the invoice later. PRO makes that a tender: checkout completes with an open invoice instead of a payment, and the receivable is visible in Magento immediately.

How It Works

When the cashier takes payment by invoice, the sale books as a normal Magento order on the payment method you configured. What happens to the invoice is the Pay-by-Invoice Invoice Behavior setting, with three modes:

• Create open invoice (default): Magento creates the invoice immediately but leaves it open: an unpaid receivable, visible in the admin next to every other invoice. When the customer's payment arrives, open the invoice and mark it paid ("Pay Offline"). Stock Magento would mark an offline-method invoice paid the moment it is created, which is wrong for a sale that has not been paid, so the module holds the invoice open for POS orders. Only POS sales are affected; invoices you create in the admin behave as before.
• No invoice: the order lands in processing uninvoiced, and you invoice manually when payment arrives. This is Magento's classic on-account flow; pick it if your accounting keys off invoice creation.
• Create paid invoice: order and invoice close immediately. Use this when payment is collected at the register, for example a cheque written at the counter.

Because everything is a standard order and a standard invoice, the sale flows into whatever dunning, accounting and ERP process you already run. There is no separate POS ledger.

Choosing the Payment Method

Pay-by-Invoice Method selects which Magento payment method carries these orders:

• Check / Money Order (default), Bank Transfer or Purchase Order: Magento's stock offline methods. Purchase Order additionally lets the cashier record the buyer's PO number at checkout.
• POS Invoice: a method the module ships that is hidden from the storefront. Pick it when you want register-side invoice sales cleanly separated from web orders in payment reports.

Credit Limits

Whether a credit check gates the tender is the Use Customer Credit Limits toggle (off by default, in which case any attached customer may buy on account). With limits on, the register resolves each customer's limit and offers the tender only to a customer with a limit above zero. An order that would exceed the available credit is a warning, not a block: the register shows that the cart exceeds the credit limit, and a cashier whose role allows invoice sales can still place it.

Where the limit comes from is pluggable, checked in order until one source answers:

1. Adobe Commerce B2B company credit: if the customer belongs to a company with company credit configured, that limit applies. Nothing to set up; the module detects the B2B modules and skips this source on Open Source.
2. The POS Credit Limit customer attribute: the module adds POS Credit Limit and POS Credit Limit Disabled fields to the admin customer edit form. Set an amount per customer; the disabled flag blocks account sales for that customer regardless of any limit.
3. Your own source: an ERP, a finance system, a third-party B2B module. See credit limit resolvers for the integration contract.

Whatever the source of the limit, the used amount is always computed the same way: the sum of the customer's open (unpaid) invoices in Magento. Available credit is the limit minus that sum, so the number at the register matches the open receivables in Magento.

Configuration

All of it lives under Stores → Configuration → Hyvä POS → Payments → Pay by Invoice:

Each location can override the method and the invoice behavior. To stop locations and devices from diverging, the Lock Settings section (Stores → Configuration → Hyvä POS → Lock Settings → Payments) has Lock Pay-by-Invoice Method and Lock Pay-by-Invoice Invoice Behavior: locked values are enforced on every terminal and show as Managed by Magento on the register; see global settings.

On the device there is nothing to configure. The tender appears at checkout when the method is enabled for the register, a customer is attached to the sale, the cashier's role allows invoice sales, and, with credit limits on, the customer has credit.

What the Cashier Sees

• For an eligible customer, Invoice appears among the tenders, and a chip shows the credit standing: current usage against the limit, green while the order fits, red when it would not.
• Tapping the chip opens the open invoices sheet: every outstanding invoice with amount and age, so the cashier can see at the register whether the account can buy on invoice, without calling the office. The same sheet is reachable from the customer's detail panel.
• When the method is Purchase Order, an optional PO number field records the buyer's reference on the order.
• If the order would exceed available credit, the chip turns red and reads "Cart exceeds credit limit". The tender stays available: the cashier can place the order anyway, remove items, take another tender, or send the customer to whoever can raise the limit.

Where the Data Lives

Credit limits live on the customer record (the attribute on the admin customer form) or in Adobe B2B's company credit; open receivables are ordinary rows in Magento's invoice table; the sale is an ordinary order. Pay-by-invoice adds no new data store.

Offline

Pay-by-invoice needs the connection. The credit standing is a live check against Magento's open invoices; a cached number could let a customer exceed their limit at two counters at once. Offline, the tender does not appear; cash and card keep working.