Odoo Invoicing, Explained for SME Finance Teams

What Is Odoo Invoicing?

Odoo Invoicing is the standalone Odoo app for creating invoices, sending them to customers, and managing payments; it also handles the matching flows for vendor bills. It is deliberately lighter than the Odoo Accounting app, which performs the same invoicing actions and adds standard financial reports, bank reconciliation, budgets, and asset management. For an SME that only needs to bill customers and pay suppliers, Invoicing is enough; the moment you need a general ledger close or bank feeds, you graduate to Accounting.

Like other Odoo finance apps, Invoicing is built on Odoo's native 'one app, one job, integrated by default' pattern: a self-contained app with its own Configuration menu that shares the same double-entry ledger as every other Odoo app. There is no separate billing database to reconcile — the journal entries a posted invoice creates are the same entries your accountant sees.

Underneath, Odoo uses double-entry bookkeeping. Every accounting transaction — a customer invoice, a vendor bill, a point-of-sale order, an expense, an inventory valuation — automatically generates the underlying journal entries, with one account debited and the other credited so the books always balance. That is what lets a standalone Invoicing app still produce audit-ready, balanced books.

Most SME billing still starts in Sales. A confirmed sales order can create a draft invoice (regular, percentage down payment, or fixed-amount down payment). Product invoicing policy decides whether you bill ordered quantities (default) or delivered quantities — critical for partial shipments and materials businesses. From there the same Confirm → Send → Pay → reconcile path applies whether the invoice came from a sales order or was typed manually.

Invoice Lifecycle and Statuses

Odoo initially creates invoices in Draft. Draft invoices have no accounting impact until you Confirm them. Confirmation moves the invoice to Posted, generates the journal entry, and assigns a unique sequence number. Once posted, you cannot edit line amounts or partners freely — use Reset to draft only when the books still allow it, or reverse with a credit note after the document is locked into the audit trail.

After posting, you Send the invoice (email, Peppol, download, or batch send from the invoice list). Customers open it on the portal when portal access is enabled. Registering a payment (manually, online, or from a bank statement) reduces the residual amount. With the Invoice Online Payment feature enabled, the portal shows a Pay Now button so the customer can pick a payment provider without your AR team re-keying cards.

Payment status is separate from the accounting state of the invoice document. In Payment means a payment has been registered and posted, often against an Outstanding Receipts account, but the bank transaction has not yet fully reconciled the residual. Paid means the invoice accounting entry is fully reconciled with payment and bank lines — the definition Odoo uses for a settled invoice. Partial payments leave a residual balance until further receipts or credit notes clear it.

Day-to-day AR still needs follow-up. Odoo's follow-up actions remind customers on overdue invoices by level (days overdue), and partner reports (Partner Ledger, Aged Receivable, Aged Payable) sit in Accounting when you need aging and cash forecasting rather than a single invoice form.

Customer Invoices and Vendor Bills

A customer invoice in Odoo starts as a Draft in the Customer Invoices journal (Accounting → Customers → Invoices, or Invoicing → Customers → Invoices for Invoicing-only users). You can create it manually or generate it from a sales order; either way, the draft holds the partner, product lines, taxes, and payment terms. Clicking Confirm moves it to Posted and writes the journal entry — debiting Accounts Receivable and crediting the revenue accounts on each line.

Vendor bills are the mirror image. Recorded in the Vendor Bills journal (Accounting → Vendors → Bills), a bill can be entered manually, captured through AI document digitization (OCR on PDFs and scans — an In-App Purchase credit per document), generated from a purchase order under a bill control policy, or received electronically (for example via Peppol). Posting debits the expense or asset accounts and credits Accounts Payable under the same double-entry rule. The vendor's own invoice number is captured on the bill so matching and tax audits stay clean.

Because invoices and bills share one ledger, the same partner card, the same tax grid, and the same chart of accounts serve both. A customer who is also a supplier appears once, with receivable and payable balances that net correctly on aged reports — something a spreadsheet-based billing process cannot do without manual reconciliation.

On the AP side, two controls matter more than retyping PDFs. First, Purchase bill control and optional 3-way matching compare the purchase order, goods receipt, and vendor bill so you do not pay for what never arrived. Second, AI digitization can draft the bill from the PDF — but it does not replace PO matching, tax review, or credit balance planning for IAP credits. Both are covered in the sections below.

Sales Order to Invoice and Down Payments

On a confirmed sales order, Create Invoice opens a Create invoice(s) dialog with three modes: Regular invoice, Down payment (percentage), and Down payment (fixed amount). Draft invoices are created first so finance can review lines, taxes, and income accounts before posting. Product invoicing policy — Invoice what is ordered (default) versus Invoice what is delivered — controls whether you can bill before delivery. Delivered-quantity policy is common for materials, liquids, and multi-shipment goods where ordered and delivered quantities diverge.

A down payment is an initial up-front amount during the sales transaction — not the same thing as payment terms or installment plans on a single invoice. Percentage and fixed-amount down payments both work. A 100% down payment is still a down payment: the sales order keeps Create Invoice available so a later regular invoice can close the commercial flow, whereas a full regular invoice of the order typically exhausts invoiceable lines and removes that path.

After a down payment invoice is posted and paid, the sales order shows a Down Payments section on the order lines. When you create the next regular invoice, Odoo shows Already invoiced and Amount to invoice so residual revenue is billed cleanly. Watch the interaction with delivered-quantity policy: if nothing is delivered and totals would go negative, Odoo may produce a credit note path instead of a negative invoice total — Inventory (or manual delivered qty on the SO) is required for the full delivery-based deduction flow.

Payment terms remain the tool for splitting one invoice residual across due dates (Net 15, installments, cash discounts). Use down payments when you need cash before fulfillment; use installment payment terms when the commercial invoice is already final but cash comes in stages.

Payment Terms and Installment Plans

Payment terms in Odoo specify the conditions of a sale's payment — due dates, early-payment discounts, and any other conditions — and are defined on documents such as sales orders, customer invoices, and vendor bills. An installment plan goes further, letting a customer pay a single invoice in parts, with amounts and dates defined beforehand.

Payment terms are configured at Accounting → Configuration → Payment Terms. Built-in examples ship with every database so you can start billing immediately:

When an invoice carries specific payment terms, Odoo generates a different journal entry: one journal item per computed due date. That produces an accurate aged receivable report, easier customer follow-ups, and cleaner bank reconciliation, because each installment lines up with its own expected deposit rather than collapsing into a single due line.

Registering Payments: Manual, Portal, and Online

Payments in Odoo can be linked automatically to an invoice or bill — reducing the amount due — or stand alone, creating outstanding credit or debit until matched later. Registering a payment is as direct as clicking Pay on the document; the status then moves to In Payment, and to Paid once the bank transaction is reconciled. Partial amounts are first-class: enter a lower payment amount and the residual stays open for the next receipt or for application of a credit note.

For manual methods, Odoo supports cash and checks. Checks can be tracked and printed directly from the database, and registering a customer payment by check does not move funds until the check is deposited and reconciled with a bank transaction — the same control a controller expects from a dedicated accounting system. For batch payouts, Odoo generates standard payment files such as NACHA (North America) and SEPA (Europe), so a finance team can pay dozens of vendors in one upload rather than typing each wire.

Customer self-serve is the cash-collection unlock for most SMEs. Enable Invoice Online Payment so emailed invoices include portal access with Pay Now. Odoo embeds payment providers (called payment acquirers before Odoo 16) that let customers pay on the portal, eCommerce checkout, or sales order — including subscriptions with tokenization where the provider supports it. Sensitive card data stays with the certified provider; Odoo is kept out of PCI DSS scope and merchants complete the provider-specific Self-Assessment Questionnaire.

Wire Transfer is typically available by default as a non-card option; online card/wallet methods need each provider enabled under Accounting → Configuration → Payment Providers (also reachable from Website or Sales configuration menus). Generate Payment Link from the invoice actions when you need a one-off shareable link outside the standard portal email flow.

• →20+ built-in providers include Stripe, PayPal, Adyen, Authorize.Net, Mollie, Razorpay, Mercado Pago, Worldline, Redsys, and more, plus a bundled Demo provider for testing. (Hundreds more connectors are available via the Odoo App Store and OCA — this list covers the natively bundled ones.)
• →Tokenization (saved cards) is supported by Stripe, Razorpay, and Adyen — useful for subscription and repeat billing.
• →Manual capture is supported by Adyen, Authorize.Net, Razorpay, and Stripe, letting you authorize at order time and capture at shipment.
• →Full and partial refunds are supported by Adyen, Razorpay, and Stripe directly from the invoice.
• →Express checkout (Apple Pay / Google Pay) is supported by Stripe.
• →PayPal hosts payment on its own flow with refunds but no tokenization or express checkout.
• →Provider processing fees are set by the provider, not by Odoo, and vary by region and card type — Odoo does not set or take a cut of those fees.
• →In Payment vs Paid: Outstanding Receipts journals keep invoices In Payment until bank reconciliation clears residual to Paid.

Credit Notes, Refunds, and Reversals

A credit note (also called a credit or debit memo) is the only legal method in Odoo for canceling, refunding, or modifying a validated invoice. Common triggers are a mistake in the invoice or vendor bill, a return of goods, a rejection of services, or damaged goods. Editing a posted invoice directly is intentionally blocked — the audit trail must show the reversal.

To issue a customer credit note, open the relevant invoice (Accounting → Customers → Invoices) and click Credit Note. The credit-note sequence starts with R followed by the related document number — for example, RINV/2025/0004 reverses invoice INV/2025/0004. Creating the credit note generates a reverse entry that cancels out the journal items from the original invoice, so the books stay balanced and the partner's receivable is corrected in the same period.

Vendor refunds work the same way: open the relevant vendor bill (Accounting → Vendors → Bills) and click Credit Note. The vendor credit note mirrors the customer flow, reversing the payable instead of the receivable. Because both sit in the same double-entry ledger, a refund that crosses a customer and a vendor (a true contra situation) still nets correctly without a manual journal. Partial residual application is common after returns: credit the returned lines, leave any still-owed residual open, then register payment only for what remains.

AI Document Digitization for Vendor Bills

Document digitization is how Odoo turns a supplier PDF (or less often a photo/scan) into a draft vendor bill without retyping every field. Using OCR and AI, Odoo reads vendor, dates, reference, amounts, and taxes, shows the original document beside the form, and leaves you to verify before posting. The same engine can touch customer invoices and credit notes when settings allow it, but day-to-day use is AP: less typing, same human control on totals, tax, and payability.

Enable it under Accounting → Configuration → Settings → Digitization. Choose automatic processing (Odoo digitizes as soon as a file lands) or on-demand (you click Send for digitization). Upload by drag-and-drop onto the purchase journal, Upload on the journal, or email: each PDF attached to the journal email alias becomes a draft bill. Only PDF and XML are processed via a journal email alias; JPEG photos go through a Documents app alias. XML e-invoices that already carry structured data do not consume OCR credits.

The cost surprise teams hit in production is the IAP meter. Document digitization is an In-App Purchase service: digitizing one document uses one prepaid credit, bought under Digitization → Buy credits (or Settings → IAP). Enterprise databases with a valid subscription receive free starter credits for testing — including demo, educational, and one-app-free databases — but ongoing volume is paid. Credits are spent when a document is sent for digitization, so a bad scan you re-send burns a second credit. Automatic mode can drain the balance quietly; when credits hit zero, digitization stops and drafts stop filling. Do not treat OCR as “included free forever” in the Odoo subscription price.

Accuracy is strong on clean PDFs from regular suppliers and improves as you correct a vendor’s layout; blurry phone photos, skewed scans, handwriting, and odd layouts need more human attention. Always check vendor, total, and tax first. After several bills confirmed with no edits, Odoo can offer auto-post for that vendor (Always / Ask after 3 validations without edits / Never) — use it only for predictable recurring suppliers (utilities, SaaS), never as a global default when lines vary or a purchase order must be matched. Digitization drafts the bill; it does not, by itself, reconcile lines to open PO quantities. Pair OCR with Purchase matching and 3-way matching when goods are involved.

Purchase Bill Control and 3-Way Matching

Invoicing sits next to Purchase: how you create vendor bills from purchase orders decides whether AP pays on order or on receipt. On each product’s Purchase tab, Control Policy is either On ordered quantities (draft bill from confirmed PO quantities even before receipt) or On received quantities (bill only after something is received; attempting a bill with zero receipt errors). Defaults follow product type: services tend toward ordered quantities; goods toward received/delivered quantities. Get this wrong and either warehouse waits forever for bills or finance pays before stock lands.

3-way matching compares three documents — the purchase order, the vendor bill, and the goods receipt — so you pay for what was ordered and received, not for fraudulent or premature invoices. Enable it in Purchase → Configuration → Settings → Invoicing → 3-way matching. Odoo documents this feature as intended only with the bill control policy set to Received quantities. When enabled, vendor bills show a Should Be Paid field on the Other Info tab with Yes, No, or Exception. New bills start as Yes once at least some PO products have been received; after full payment the field moves to No.

If you edit a draft bill (higher quantity, different price, extra product), Should Be Paid becomes Exception: Odoo flags the discrepancy but does not hard-block the edit, because legitimate overages and freight lines exist. That is a control signal for AP review, not a silent approval. Partial receipts produce draft bills only for received quantities; you can still adjust the draft, but residual ordered quantity waits for further receipts or a conscious Exception. Billing Status on the PO (Nothing to Bill, Waiting Bills, Fully Billed) depends on the control policy — ordered-quantity policies never show “Nothing to Bill” after confirm the way received-quantity policies do before stock arrives.

Operational rule of thumb: services and prepaid vendor commitments → ordered quantities; stocked goods and anything fraud-sensitive → received quantities + 3-way matching. Combine with AI digitization carefully: OCR can create the draft from the PDF, then AP matches PO lines and checks Should Be Paid before registering payment. Skipping match is how companies double-pay or pay for goods that never hit the dock.

Electronic Invoicing, Peppol, and Localizations

Electronic data interchange (EDI) is how companies exchange invoices and related documents in standard machine-readable formats. Governments increasingly require structured e-invoices for fiscal control; Odoo supports e-invoicing in many countries through core EDI formats plus fiscal localizations. By default, the send window offers formats that match the customer's country; you can also pin a specific format on the partner Accounting tab under Customer invoices.

From a confirmed invoice, click Send, enable the relevant e-invoicing option (for example by Peppol), and send to generate and attach the XML. Batch send from the invoice list works for large runs. Peppol is the pan-European (and UK-eligible) network for exchanging electronic invoices and bills: Odoo can act as both an access point and SMP so you send customer invoices and credit notes and receive vendor bills without email PDFs as the system of record. Peppol registration in Odoo is free and available in Community; supported send formats include BIS Billing 3.0, XRechnung CIUS, and NLCIUS for eligible countries listed in Odoo 19 documentation.

Registration lives under Accounting → Configuration → Settings → PEPPOL Electronic Invoicing: activate electronic invoicing, set the country-specific Peppol endpoint identifier (usually company registry or VAT), email, and phone with country code, then Activate Peppol. Choose whether incoming documents land in a purchase journal as draft vendor bills or in the Documents app workspace. Verify each customer contact's Peppol endpoint before first send — Odoo can prefill numbers, but wrong endpoints are a common production failure. Status filters such as Peppol Ready and a Peppol status column on the invoice list help AR track delivery to Done.

Country-specific regimes still matter beyond Peppol: Argentina, Brazil, Mexico, Italy, Saudi Arabia, Spain, and many others have dedicated localization pages in Odoo. Practitioners discussing 2026 reforms (for example French Factur-X / PDP flows, UAE FTA e-invoicing, India GST e-invoice and e-Way Bill) emphasize archive continuity, invoice numbering continuity when changing platforms, and day-to-day lifecycle features such as paid copies — not only XML generation. Implement the localization that matches your company's registered country, then test send/receive in a demo Peppol endpoint before production cutover.

2026 is a hard-compliance year for many EU SMEs on Odoo. Belgium requires domestic B2B e-invoicing over Peppol from 1 January 2026; Odoo positions itself as a free Peppol access point for send and receive. France’s B2B e-invoicing reform targets 1 September 2026 for receive obligations (with large/mid-size issue obligations through approved platforms); Odoo documents certification as a Plateforme Agréée (PA) for free send/receive in that regime. Practitioners still stress master-data cleanup (VAT/endpoints), archive and numbering continuity, and distinguishing platform rejection from buyer refusal — not only flipping a Peppol switch. Test in demo mode before production registration, and remember only one active Peppol receiver registration is allowed per endpoint.

The Dynamics 365 Equivalent for SMEs

Dynamics 365 Business Central — the SME SKU most comparable to Odoo Invoicing — maps the same flow onto formal document types. You create a sales invoice (or sales order) to record the agreement to sell products on certain delivery and payment terms; posting the sales invoice creates the related quantity and value entries, and you can email it as a PDF with a payment summary such as a PayPal link.

Posted sales invoices and posted purchase invoices appear in their respective Posted lists with the final invoice numbers. You can correct or cancel an unpaid posted sales invoice, but a paid posted sales invoice must be reversed with a sales credit memo — the same legal-reversal rule Odoo enforces, expressed as a formal document type rather than an R-prefixed sequence.

Business Central also supports several ways to register customer payments: manually via Register Customer Payments, automatically via payment reconciliation that matches bank receipts to open invoices, and through payment services by filling in the Payment Method Code (and Payment Service for electronic payments) on the sales document. A purchase invoice or purchase order records the cost of purchases and tracks accounts payable; posting it updates inventory and financial records and activates vendor payment according to the payment terms, with the vendor's own invoice number captured in the Vendor Invoice No. field.

Payment methods in Business Central define how customers pay you and how you pay vendors — bank, cash, check, or account — and the same Payment Method table serves both sales and purchase documents. Credit memos are an exception: because money flows in the opposite direction, a default payment method is intentionally not assigned to them.

Dynamics 365 Finance, the larger enterprise SKU, replaces the Business Central document model with free-text invoices, vendor invoices, and customer payment journals under Modules > Accounts receivable and Accounts payable. The conceptual mapping — customer invoice, vendor invoice, credit memo, payment terms, payment methods — is the same; the headline difference is that Business Central and Finance ship sales and purchase documents as part of one integrated ERP, where Odoo splits billing into a lighter Invoicing app and a fuller Accounting app.

When Each Fits an SME

Choose Odoo Invoicing when billing is genuinely simple — a handful of customers, manual or portal payments, no bank reconciliation needed today — and you want the option to grow into Odoo Accounting later without re-platforming. The standalone app keeps day-one setup short while sharing the same ledger you will keep using.

Choose Odoo Accounting (instead of just Invoicing) the moment you need bank reconciliation, budgets, asset management, or standard financial reports. Because Invoicing is a subset of Accounting, the upgrade is a configuration change, not a data migration. Multi-country Peppol or localization work usually lives more comfortably in Accounting with full journals and documents routing.

Choose Dynamics 365 Business Central when your SME already lives inside the Microsoft stack — Outlook, Teams, Excel, Power Platform — and you want sales and purchase documents treated as first-class ERP document types with deep Microsoft integration. Business Central is positioned for SMEs that expect to grow into a broader financial-management footprint.

In every case, the decision should follow your existing stack and your team's actual billing workflow, not a vendor's feature checklist. Flectic implements both Odoo and Dynamics 365 and is platform-neutral: the goal is the right fit for the SME, not a preferred vendor.

Getting Started Responsibly

1. 01
   Confirm the app scope

   Decide up front whether Invoicing alone is enough or whether Accounting is the right starting point. If bank reconciliation, budgets, formal financial reports, or multi-country e-invoicing are on the near-term roadmap, start with Accounting to avoid a later configuration-only migration.

2. 02
   Configure the chart of accounts and taxes first

   Payment terms, journals, and tax grids all depend on a correct chart of accounts. Lock this down before creating real invoices so that posted entries land in the right accounts from day one.

3. 03
   Set invoicing policies, payment terms, and providers before go-live

   Pick ordered vs delivered quantity policies per product family, configure the payment terms you actually use (Net 15, Net 30, 2% 10 Net 30), and enable the payment providers you need (Stripe, PayPal, etc.) under Accounting → Configuration. Test a sandbox invoice end-to-end — including portal Pay Now — before opening billing to customers.

4. 04
   Train the team on credit notes and down payments

   The single biggest behavioural change for teams coming from spreadsheets is that a posted invoice is never edited — it is reversed with a credit note. Train AR and AP on Credit Note and on the Create Invoice down-payment dialog so deposits do not get retyped as ad-hoc journals.

5. 05
   Decide digitization and IAP credit budget

   If AP volume justifies OCR, enable Document Digitization, start on-demand, set the vendor-bills email alias, and buy a credit buffer before go-live. Document that one digitized document = one IAP credit, XML structured bills may skip OCR, and re-sends cost again. Reserve auto-post for clean recurring vendors only.

6. 06
   Set Purchase bill control and 3-way matching

   Align product control policies (ordered vs received quantities) with how you actually buy. For goods, prefer received quantities and enable 3-way matching so Should Be Paid reflects receipts. Train AP to treat Exception as a review queue, not a green light.

7. 07
   Register Peppol or country EDI only after partner data is clean

   Verify VAT/registry endpoints on customers, choose journal vs Documents reception for vendor bills, and run a demo Peppol endpoint test before production activation. Deregister cleanly if you ever leave Odoo as the access point — only one active Peppol registration is allowed per endpoint.

8. 08
   Plan the bank-reconciliation cutover

   Even if you start on Invoicing, plan how and when you will adopt bank reconciliation so In Payment actually becomes Paid. Reconciling the first month cleanly is the difference between a ledger you trust and one you re-check every quarter.

Frequently asked questions