Slovenian Prepayment Invoice Accounting

English | Slovenščina

Manage customer advances from sales order through receipt, VAT recognition and invoice settlement. The module extends Sales and Accounting, keeping the payment, application and reporting evidence linked throughout the accounting lifecycle.

Choose manual application or automatic application during invoice posting, then inspect the linked entries and Advance Applications history. Company accounts, journals and settlement mode control the resulting postings.

The implemented flow is:

A sales order supplies the customer, currency and taxes for the advance.
An inbound customer payment records the received advance.
A VAT-on-receipt entry records the proportional sales-order taxes.
An application settles the advance against a partial or final customer invoice using the configured settlement mode.
Application lines and reporting allocations retain payment, invoice and tax-bucket ownership for audit and downstream reporting.

The advance document is a payment PDF report, not a separate Odoo invoice. Vendor advances are outside the supported operational scope.

Table of contents

Documentation

User Manual: illustrated advance setup and draft preparation, manual/automatic application, bank matching and corrections.

Features

Customer advances

Adds an Advance? flag, advance account, company VAT clearing account, sales-order link, tax totals, advance ratio and remaining amount to payments.
Supports inbound customer payments only. A model constraint rejects outbound or supplier payments marked as advances; vendor advance menus are hidden.
Posts the payment against a reconcilable customer advance account and creates VAT-on-receipt accounting through Odoo's core tax pipeline.
Uses tax repartition accounts and tags from the linked sales order.
Values VAT in company currency at the payment date.
Preserves the tax pipeline's signed taxable bases, including negative order lines. Stored bases already follow reporting direction; readers must not apply ledger inversion a second time.
Preserves signed reverse-charge tax components. Offsetting components do not increase gross settlement capacity or create a net VAT-clearing balance.
Enforces reconciliation on accounts marked used_for_prepayment.
Provides Without Follow-up Invoice in the Advances list's Filters menu. It selects advances without a linked draft or posted customer invoice through an active application, including legacy applications. Cancelled applications and cancelled invoices do not count. An advance with even a partial invoice application is linked, regardless of its remaining amount; a sales-order link alone does not count as an invoice application.
Adds a Follow-up Invoices smart button to the advance form, using the same non-cancelled application links as the list filter. It counts each accessible invoice once, opens a single invoice directly, or lists multiple invoices. The button is hidden when no follow-up invoices are linked.
Provides Find Bank Transaction for posted bank advances that still need bank matching, including partially matched receipts. The button is hidden once the payment is fully matched. Accountants can search by partner (including unassigned transactions), bank journal, date range, amount range in the advance currency, and label/reference. Clear the partner to include misassigned partners, or disable amount matching to widen the search. Already-reconciled transactions are optional.
Candidate rows open the current journal entry, the bank statement's native Revert reconciliation workflow, or the installed OCA reconciliation form. Transactions without a statement open the native transaction list for review. These navigation actions require the existing OCA bank-statement views; the addon does not install a reconciliation engine. Match the advance payment's outstanding receipt, not the VAT-on-receipt entry. The finder never undoes, reassigns, or reconciles bank transactions itself, and does not bypass access rights or the native accounting workflow.

Sales orders

Adds Advances > Create Advance, related advance access, and advance and unpaid amount tracking to sales orders.
Defaults new advances to the order currency, commercial invoice partner, company advance account and currently unpaid amount.
Allows parent and child contacts within the same commercial partner.
Requires the advance currency to match the linked sales-order currency.
Guards the standard Sales down-payment methods percentage and fixed when the company fiscal country and customer invoice-address country are both Slovenia and the incoming advance account, VAT account and advance journal are configured.
The guard raises a warning with a Settings link and instructions to use Advances > Create Advance. It does not create a payment automatically. Regular delivered-quantity invoicing remains available.

Settlement modes

Auto (SI settlement entries) is the default. It uses settlement journal entries when SI settlement processing is eligible; manual application otherwise falls back to the neutralizer flow.
Settlement Journal Entry settles receivables and VAT in a linked entry. It also adds tax-bucket base-reporting lines and balancing offsets on the settlement account, with no net balance on that account.
Neutralizer Entry settles receivables and neutralizes advance VAT in a linked journal entry. This mode supports manual application and does not activate invoice-posting auto-apply. For Slovenian companies, it also adds balanced tax-bucket base-reporting lines, preventing the advance base from being counted again with the final invoice. These use the settlement account when configured, or the invoice's first accountable line account otherwise, with no net balance on that account. The same rule applies to Auto's manual neutralizer fallback.
Settlement Lines prepares negative base and tax lines on the draft invoice using the advance buckets' exact taxes. The application entry debits the advance balance and credits VAT clearing and the settlement base account. No separate receivable counterpart is needed because the negative invoice lines already reduce the invoice balance.
SI settlement processing requires an SI fiscal country, a settlement account and an enabled l10n_si_accounting flag when that field is present. A settlement account alone does not select Settlement Lines mode.
Settlement invoice lines can only be prepared while the invoice is draft. The manual wizard on a posted invoice cannot add them.

Advance application

Applies one advance across several invoices or several eligible advances to one invoice, subject to residual and tax-bucket capacity checks.
Validates company, commercial partner, currency, partner type, account compatibility and the application period.
Consumes advances in payment-date FIFO order and reconciles the consumed advance and VAT-clearing balances with their original payment evidence.
In journal-entry modes, neutralizes VAT within the invoice tax evidence and remaining advance VAT capacity.
In Settlement Lines mode, uses the advance tax buckets and the negative invoice lines' tax effects.
Keeps calculated bucket VAT and assigns small rounding remainders to the largest base bucket. Material discrepancies and already-consumed capacity remain subject to validation.
Preserves transaction-currency ownership alongside company-currency values. Standard Odoo reconciliation handles exchange differences when rates differ.

Automatic application

Runs synchronously when a draft customer invoice is posted, when Auto-apply Advances on Posting and an eligible SI settlement mode are enabled.
Discovers advances through the invoice lines' sale_line_ids and their originating sales orders. Matching the customer alone is insufficient.
Selects advances in in_process or paid state with positive residuals, matching company, commercial partner and transaction currency.
Reuses the manual wizard's allocation and settlement logic.
Prepares negative settlement lines before posting in Settlement Lines mode, then posts the linked application entry and performs reconciliation.
Supports successive partial invoices using only the remaining advance and tax-bucket capacity.
Checks for an existing linked application move before finalization creates another one. Required validation, posting or reconciliation failures abort the invoice posting transaction.

Documents and application history

Prints and attaches an advance payment PDF and adds advance information to invoice reports.
Derives the advance document number from the posted advance journal entry, with a manual Printed Advance Number override.
Limits partner synchronization to draft advance moves; computed fields do not rename or rewrite posted journal entries.
Adds Accounting > Customers > Advance Applications to inspect payments, invoices, generated moves, represented amounts and application lines.
Keeps cancelled applications as historical evidence, excluded from active represented totals.
Refreshes durable reporting allocations after supported application and reset workflows. Tax-book position mappings are optional and require the installed account.tax.book.tag.map model.

Corrections

Supports invoice reset and reapplication with cleanup of generated application evidence and restoration of advance residuals.
Provides Reset Advance Chain to Draft to users with the Advance Invoice Manager role and normal accounting access after invoices using the advance have been reset through their supported workflow. Advance forms show this button instead of the ordinary Reset To Draft button. Both server actions enforce the same manager-only chain workflow, including when called from shortcuts or mixed payment selections.
Requires bank-statement matches, including partial matches, to be undone before resetting an advance. Locked entries retain their native protection, and a failed reset rolls back all chain cleanup. Reset the originating advance through its payment form instead of resetting its journal entry.
Protects derived posted entries from direct reset and preserves the original payment move when removing generated chain evidence.
Uses a private in-process reset authorization; client context booleans do not authorize protected resets.
Provides Prepayment VAT Backfill to preview missing-neutralizer cases and create separate linked correction entries.
Provides Change Prepayment Adjustment Date to repost eligible adjustments within the existing sequence period and restore reconciliation.

Configuration

Install the module with its declared dependencies: base, account, pmis_account_dates, sale and l10n_si_config. The addon is not auto-installed.
Under Accounting > Configuration > Settings > Advances, configure Default Advance Journal, Incoming Advance Account and Incoming Advance VAT Account for each company.
Both incoming accounts must be reconcilable. The advance account can be selected on the payment; the VAT clearing account is company-wide and read-only on payments.
Configure Advance Settlement Account and Advance Settlement Mode for SI settlement processing. The settlement account carries base-reporting lines and offsets in journal-entry mode or negative base lines in Settlement Lines mode.
Enable Auto-apply Advances on Posting for automatic application. Neutralizer Entry mode does not support it.
Configure an Outstanding Receipts Account on the bank journal's payment method so Odoo creates a payment journal entry. Advance posting fails when no payment move is created.
Configure sales-order taxes with the required tax repartition accounts and reporting tags. The sales-order link is required when posting an advance.
The application, backfill and adjustment-date wizard models grant access through account.group_account_invoice. The payment-chain reset button is restricted to account.group_account_manager.
Advance Invoice Operator has read-only access to application evidence and reporting allocations. Advance Invoice Manager has management access. Applicable company record rules restrict evidence visibility.
Assign these roles through the Advances selection under Accounting on the user's Access Rights tab. Manager includes Operator permissions.

Usage

Create and post a customer advance:

Create or open the customer's sales order with the intended currency, products and taxes.
Use Advances > Create Advance, or create an inbound customer payment through Accounting > Customers > Advances.
On the draft payment, enable Advance?, link the sales order, and review the amount, payment date, bank journal, advance account and printed number. The amount may cover only part of the order.
Post the payment. Odoo creates the ordinary payment entry; the addon creates the VAT-on-receipt entry when tax lines are generated. An advance without tax postings does not require an empty VAT entry.
Print the advance payment report when required.
Match the bank statement to the original payment move. The application entry represents settlement and does not represent another bank movement.

Apply advances manually in a journal-entry mode:

Select one or more posted customer invoices from the same company, commercial partner and currency.
Use the Apply Advance form button or Apply Advances action.
Select eligible advances and review the journal and application date.
Confirm the wizard. It posts the advance/receivable settlement and VAT neutralization. Eligible Slovenian flows also include balanced base-reporting lines in Settlement Journal Entry and Neutralizer Entry modes.
Review reconciled balances and Advance Applications evidence.

Selecting several advances whose combined remaining amount exceeds the selected invoice residual is rejected in journal-entry modes. Settlement Lines mode requires draft preparation through the automatic posting workflow.

Apply advances automatically:

Enable auto-apply and configure an eligible SI settlement mode.
Create the partial or final customer invoice from the sales order. Keep the invoice lines linked to their originating sales-order lines.
Post the invoice. Before posting, the addon discovers eligible advances, validates the period and prepares allocations. In Settlement Lines mode, it adds the negative settlement invoice lines at this stage.
After Odoo posts the invoice, the addon creates the linked settlement_application entry and reconciles the consumed advance, VAT clearing and, for journal-entry mode, invoice receivable.
Review the application lines and refreshed reporting allocations.
Repeat for later invoices. Each posting consumes only the remaining advance and tax-bucket capacity.

An invoice entered without sales-order-line links has no originating order for auto-apply discovery. Auto-apply also skips when disabled, when SI settlement eligibility is absent, when no linked advance has a positive residual, or when the invoice total is zero. Once settlement processing is eligible, missing incoming accounts or the advance journal raises an error. Currency mismatches, locked application dates and ambiguous historical ownership block processing when encountered.

Reset, correct and reapply an advance:

Reset every invoice with an active application of the payment through the supported invoice reset workflow. This unwinds the generated application evidence and reconciliations and restores the corresponding advance balance.
Use Reset Advance Chain to Draft on the payment. The action refuses to proceed while active invoiced applications remain or historical payment and sales-order currencies disagree. Undo any bank-statement matching first; partially matched receipts also require this step. An Advance Invoice Manager must confirm the chain reset.
Correct the draft payment and repost it.
Repost eligible invoices for auto-apply, or use the manual journal-entry application workflow. Cancelled application records remain historical evidence; the replacement chain uses new active evidence.

Backfill a missing VAT neutralizer:

Review the historical application with an accountant.
Open Accounting > Configuration > Prepayment VAT Backfill.
Select the company, date range and date policy: Invoice Date, Application Date or Correction Date (Today). Invoice Date uses the latest invoice date when several invoices are linked.
Use Preview to inspect eligible application moves.
Use Run Backfill to create a separate linked VAT Neutralizer (Backfill) entry per eligible application and reconcile its VAT clearing. Execution does not edit the original posted application move.

Backfill computes VAT from the payment's original VAT ratio, applied gross amount and invoice tax totals. Selected dates remain subject to posting and tax-date locks. Historical payment/order currency mismatches require a controlled correction and cannot be backfilled automatically.

Change an adjustment date:

Open the adjustment journal-entry form and use Change Prepayment Adjustment Date.
Select a new date within the existing entry's sequence period.
Apply the change. The wizard resets and reposts the entry, verifies that its number remains unchanged, and restores reconciliation with previously matched lines.

The wizard accepts posted neutralizer or settlement_application entries from one company. It does not accept the original payment or VAT-on-receipt entry. Normal posting and lock checks still apply.

Example posts

These independent examples use Neutralizer Entry mode, EUR and ordinary 22% sales VAT. Account codes are illustrative; postings use configured accounts. For Slovenian companies, Neutralizer Entry mode also adds base-reporting lines and balancing offsets; they do not change the net account balances illustrated below. Settlement Journal Entry mode supplies its own balanced base-reporting lines. Settlement Lines mode reduces the invoice itself before posting.

Receive a 61.00 advance against an order of 100.00 base plus 22.00 VAT:

Payment entry: debit 110000 Outstanding receipts 61.00 and credit 230000 Received advances 61.00.
VAT-on-receipt entry: debit 195000 VAT on advances received 11.00 and credit 260002 Output VAT - 22% 11.00.
The sales-order tax pipeline uses the payment/order ratio of 61.00 / 122.00.

Apply that unused advance to an invoice of 61.00:

Application entry: debit 230000 Received advances 61.00 and credit 120000 Account Receivable 61.00.
In the same entry, debit 260002 Output VAT - 22% 11.00 and credit 195000 VAT on advances received 11.00.
Reconciliation clears the advance, invoice receivable and original VAT-clearing debit.

Apply an unused 61.00 advance to a larger invoice:

For an invoice of 122.00, apply the same 61.00 advance and 11.00 VAT clearing; the invoice retains a receivable balance of 61.00.
For an invoice of 244.00, apply the same 61.00 advance and 11.00 VAT clearing; the invoice retains a receivable balance of 183.00. Of its 44.00 VAT, 33.00 remains after the 11.00 neutralization.
Each case consumes the advance in full.

Apply a 122.00 advance across two partial invoices:

Start with an advance of 100.00 base plus 22.00 VAT.
Apply 61.00 to the first invoice of 50.00 base plus 11.00 VAT. This leaves 61.00 of advance capacity and 11.00 of VAT clearing.
Apply the remaining 61.00 to a second invoice with the same base and VAT. This exhausts the advance and clears the remaining 11.00 of VAT.
Later invoices from the order post without another application once the advance residual is zero.

Data model notes

account.payment holds the advance flag, sales-order reference, advance account, remaining amount and generated VAT-move reference.
pmis.prepayment.application ties a payment chain to its source move, VAT-on-receipt move, invoices and generated application, neutralizer or settlement moves. One active invoice-application record represents one explicit payment chain.
pmis.prepayment.application.line stores source move lines, invoice references, tax-bucket identifiers and represented base, VAT and gross. Represented company-currency base plus VAT equals gross within currency rounding.
Shared generated moves retain durable payment/source ownership. Explicit applications are preferred; legacy discovery does not guess ambiguous ownership or reconstruct historical accounting evidence.
pmis.prepayment.reporting.allocation retains tax-bucket and tax-tag position evidence for downstream reporting. Without account.tax.book.tag.map, position mapping is empty.
originator_move_id and originated_move_ids link source and generated journal entries. Classified VAT move types include vat_on_receipt, neutralizer and settlement_application.
Payment posting uses Odoo's tax pipeline to calculate advance tax evidence. Manual application and invoice-posting auto-apply share allocation and settlement helpers. Supported lifecycle changes refresh durable reporting allocations through pmis.prepayment.reporting.allocation.service.
Manual neutralizer entries initially use the earliest linked advance-move date when available, with the wizard date as fallback. Settlement entries use the application date, defaulted from the invoice date.
The adjustment-date wizard's _pmis_update_tax_date() is an extension hook with no implementation in this addon. Changing the posting date does not supply missing historical tax dates.
Application identity, application lines, invoice application chains and reporting-allocation replacement use serialization fences and deterministic record ordering. PostgreSQL serialization conflicts require retrying the complete business transaction.
Shared accounting and Tax Date fields come from pmis_account_dates. Generated entries supply dates through the advance posting and application workflows; Slovenian reporting extensions enforce their additional tax locks.

Known limitations

The addon provides transactional accounting and reporting evidence, not financial summaries or reporting dashboards. Actual tax treatment and reporting depend on configured accounts, taxes, repartition tags and installed Slovenian reporting extensions.
Vendor/purchase advances are not implemented. Missing company or invoice address countries do not activate the Slovenian Sales down-payment guard.
Auto-apply runs during invoice posting; it is not a scheduled job that searches all customers and open advances.
The sales order, payment and invoice must share the transaction currency. Company-currency valuations can differ by date; reconciliation handles the exchange difference without fabricating a second FX event.
Historical payment/order currency mismatches and ambiguous application ownership block supported application and reset paths.
Reverse-charge source entries must have correct component signs before application; the application workflow does not repair their accounting.
Missing historical tax dates are not inferred or backfilled. Missing VAT neutralizers require the separate backfill entry; date corrections use the explicit adjustment-date wizard.
Report reads consume durable chain and allocation fields and do not justify recomputing or mutating posted accounting evidence.

Troubleshooting:

Check that both the advance and VAT clearing accounts are reconcilable.
Check the linked sales order, tax repartition accounts, company advance journal and bank payment method's Outstanding Receipts Account.
If a posted invoice raises a draft-only settlement-line error, review the settlement mode and use the draft auto-apply workflow.
If auto-apply does nothing, check SI eligibility, the company toggle, sales-order-line links and remaining advance capacity.