The payment is made in the bank's website. The ledger finds out on Thursday.
Two systems, one act, and a person in between retyping. The bill is approved in the ERP, the transfer is keyed into the bank portal, and the ledger is told afterwards, sometimes the same day, sometimes when the statement is reconciled. Nothing is wrong with either system. What is wrong is that the record of what was paid and the act of paying it are separated by a browser tab, and everything downstream of that, which invoices are actually settled, what the vendor thinks is outstanding, whether the same bill went out twice, depends on somebody having typed the same number the same way in both places.
What you get with payment management
Payments live on the same ledger as the documents they settle. A payment is registered against the invoices or bills it clears, and each invoice shows its own state, unpaid, partially paid, in payment, paid, reversed or blocked, next to the amount still outstanding and the payments matched against it. Credit notes and refunds are part of the core ledger, not an add-on. Vendors and customers each carry their own payment term, their own payable or receivable account, and their own bank details.
On the inbound side, a customer can pay a posted invoice by card without leaving it. Odoo comes with a payment framework already built in, with providers for Stripe, PayPal, Adyen, Mollie, Razorpay, Authorize.net, Worldline and eleven others, each switched on from the standard system and configured with your own merchant credentials.
And the invoice that goes out can be a structured document rather than a PDF. Odoo generates seven e-invoice formats out of the box, Factur-X for France, Peppol BIS 3.0 for the EU, ZUGFeRD and XRechnung for Germany, NLCIUS for the Netherlands, and BIS Billing 3.0 for Australia/New Zealand and Singapore, with the format chosen per customer and picked when you send.
Where payment management comes from
The card providers and the e-invoice generation are already in Odoo, nothing to add, no upgrade tier to reach, no extra fee per user, and it runs on a deployment you own. Transmission for Peppol and around twenty country tax authorities ships in the same box, ready to switch on. NetSuite bills payment features as a module and a per-seat renewal; in Odoo these are already included, and that difference is the product.
Emitting a payment file to a bank is the honest boundary. Recording a payment tells the ledger it happened; on its own it instructs no bank. Odoo's own ACH, EFT, direct-debit and batch-payment files sit in the paid Enterprise edition, and around that there are partial routes that are not equivalent, cheque printing is in the base system, and there is a free add-on for euro credit transfers, while a US ACH file is something we have not yet found for free. There is no US e-invoicing format in the box either: the seven formats above are European and Asia-Pacific. If your payment run is ACH, put it on the table on the first call, not because the answer is no, but because nobody should take it from a web page.
What does it mean to register a payment in an accounting system, and does money move?
Registering a payment creates the accounting record that a payment happened: it debits or credits the bank or cash account, clears the corresponding receivable or payable, and marks the invoice or bill it settles as paid in full or in part. It does not, by itself, instruct any bank to do anything. That distinction is easy to lose because both acts get called "paying", and it matters at evaluation time more than at any other moment: an ERP that registers payments keeps your ledger correct, while an ERP that also emits payment instructions, an ACH or SEPA file, a printed cheque, a direct-debit collection, removes a second system from the process. Ask which of the two a product does, and if it does the second, ask which file formats and in which edition, because this is one of the most common places where a capability shown in a demo turns out to sit in a higher tier.
What is e-invoicing, and how is it different from emailing a PDF?
E-invoicing is the exchange of an invoice as structured data that the recipient's system can read without a human transcribing it, typically an XML document in an agreed schema such as UBL or CII, often transmitted through a network like Peppol or submitted directly to a tax authority's platform. A PDF, however neatly laid out, is a picture of an invoice: the receiving system has to guess at its fields, which is why invoice capture and OCR exist as an industry. The practical consequence for a buyer is that e-invoicing is not one feature but a per-country obligation. Each mandate has its own format and its own transmission route, and support for one country implies nothing about another, so the useful question is never "does it do e-invoicing" but "which of the countries I invoice into does it cover, and what happens in the ones it does not".
What should a company check about outbound payment rails before choosing an ERP?
Three things, in this order: which instrument, which file, and which edition. The instrument is what actually leaves, a domestic credit transfer, a cheque, a direct-debit collection you initiate against a customer's mandate, and organisations often assume the ERP covers the one they use because it covers a different one. The file is the format the bank will accept, which is national rather than universal: a system that produces SEPA credit transfers for the euro area produces nothing a US bank will take, and vice versa. The edition is whether the capability is in the product you are buying or in a tier above it, which is worth establishing in writing rather than in a demo. Oracle markets NetSuite's payment management on exactly this ground, and states it plainly: the product will "simplify the creation of electronic payment files", with outbound features including "online bill pay, ACH payments, direct deposit and other electronic funds transfer (EFT) options". That is a real capability and it is worth wanting. It is also the specific thing to hold a vendor to, because the gap between "payments are managed here" and "the bank file is produced here" is where the second system quietly survives a migration.
Can customers pay an invoice by card without a separate payment portal?
Yes, where the accounting system carries a payment-provider framework rather than treating card acceptance as an external step. In that arrangement the invoice itself carries the payment link, the customer pays with a card through the provider you have configured, a Stripe, a PayPal, an Adyen, a Mollie, and the resulting payment is registered against that invoice rather than arriving later as an unattributed deposit to be matched by hand. What this does not remove is the commercial relationship: you still hold the merchant account, the provider still takes its fee, and the provider's own compliance obligations are still the provider's. What it removes is the reconciliation step between a payment page and a ledger, which is the step where card receipts most often go missing.