Advance payments in accounting are conceptually simple. A customer pays part of an order upfront, you apply that amount to the final invoice, and the remaining balance gets settled at delivery. Every ERP system handles this. But throw Peru’s tax authority into the mix and the simplicity evaporates.
SUNAT — Peru’s national tax administration — does not allow negative amounts in electronic invoice filings. That single restriction breaks the standard advance payment flow used in most accounting software, where the down payment appears as a negative line item on the final invoice to offset what was already paid. In Peru, that negative line gets rejected at filing time. No exceptions.
The Problem with Standard Down Payment Flows
In a typical Odoo advance payment workflow, the system creates a down payment invoice, registers the payment, then generates a final invoice that automatically includes the down payment as a deduction line. Clean, automated, and completely incompatible with SUNAT’s requirements.
Peruvian businesses using Odoo have been stuck finding their own workarounds — some processing everything manually, others using custom scripts, a few just avoiding advance payments entirely. None of those are real solutions for businesses that collect deposits as standard practice, which includes most of Peru’s construction, manufacturing, and wholesale sectors.
How the New Workflow Handles It
Odoo now documents a specific eight-step workaround that keeps advance payments compliant with SUNAT while staying within the standard accounting module. The approach uses credit notes instead of negative invoice lines, which SUNAT accepts without issue.
The workflow starts normally: open a sales order, request a down payment as either a percentage or fixed amount, and confirm the draft invoice. The divergence from the standard flow comes at the final invoice stage.
Instead of letting Odoo automatically deduct the advance payment on the final invoice, the process requires manual intervention. When creating the regular invoice from the sales order, you need to remove both the section separator and the down payment line using the trash icon. This produces a clean final invoice with no negative amounts — exactly what SUNAT expects.
The Credit Note Bridge
The advance payment still needs to be accounted for, and that’s where the credit note comes in. After creating the final invoice, you generate a credit note by reversing it, clear all the automatically populated product lines, and add a single line with the down payment description and amount.
This credit note offsets the advance payment against the final invoice. The reconciliation ties everything together: original down payment invoice, final invoice, and credit note all balance out. The remaining amount — the difference between the full order and the advance payment — gets collected through a standard payment transaction.
Why This Matters Beyond Peru
SUNAT’s restriction on negative amounts isn’t unique. Several Latin American tax authorities impose similar constraints on electronic invoicing. Guatemala, the Dominican Republic, and Chile each have their own filing rules that can collide with standard ERP advance payment logic.
The fact that Odoo is documenting country-specific workarounds at this level of detail signals a shift in how the platform handles Latin American fiscal compliance. Rather than building one-size-fits-all features that break at the edges, the approach is to surface the exact steps needed for each jurisdiction, including the manual interventions that automated systems can’t handle.
For Peruvian businesses running Odoo, this eliminates a genuine pain point. The advance payment workflow was always technically possible, but figuring out the SUNAT-compliant path required either local consulting expertise or trial and error with the tax authority. Having the workaround built into the official documentation means fewer rejected filings and fewer panicked calls to the accountant.