Overslaan naar inhoud

Het account.move-model: Odoo-facturen en journaalposten Begrijpen

Uitgebreide handleiding voor Odoo’s centrale boekhoudmodel, speciaal voor ontwikkelaars en functionele consultants
10 maart 2026 in
Het account.move-model: Odoo-facturen en journaalposten Begrijpen
Dasolo
| Nog geen reacties

Inleiding


In Odoo bepalen modellen hoe bedrijfsgegevens worden georganiseerd en bewaard. Alles waarmee je in een bedrijf werkt — offertes, facturen, boekingsposten — krijgt een plek in een model dat de velden en relaties definieert.


Kennis van Odoo-modellen is cruciaal, zowel voor ontwikkelaars als voor functionele consultants. Modellen vormen de ruggengraat van de data-architectuur: ze bepalen welke velden bestaan, hoe records aan elkaar gelinkt zijn en waar de logica draait.

In dit artikel zoomen we in op één van de hoekstenen van de boekhouding in Odoo: het account.move-model. Of je nu rapporten bouwt, koppelt met externe systemen of facturatieprocessen inricht, dit model komt onvermijdelijk langs.

Wat is het account.move-model


Het account.move-model staat voor boekingen en documenten in de boekhouding. Sinds Odoo 13 werden klantfacturen, leveranciersfacturen, creditnota's en manuele journaalposten samengebracht in één model: account.move — één centrale plek voor al die documenten.


Binnen de boekhoudmodule fungeert account.move als parent van account.move.line, waar de individuele debet- en creditregels zitten. Een factuur, een leveranciersfactuur of een journaalpost is in Odoo altijd één account.move met één of meerdere regels.


De definitie van dit model vind je in de account-module; andere modules breiden het uit via model-inheritance. De verkoopmodule voegt bijvoorbeeld functies toe om facturen te maken vanuit orders, aankoop voegt bill-creatie toe — zonder het basisontwerp te dupliceren.

Belangrijke velden in het model


Hierna behandelen we de belangrijkste velden van account.move. Wie deze kent, kan efficiënter werken met facturen, bills en journaalposten in Odoo.


1. name

Type: Char. Bewaart het nummer of de naam van de boeking (bijv. factuurnummer). Meestal automatisch gevuld via de sequence van het journaal. Wordt zichtbaar in lijsten en op afdrukken.


2. move_type

Type: Selection. Geeft het soort boeking aan: entry (manuele journaalpost), out_invoice (klantfactuur), out_refund (creditnota klant), in_invoice (leveranciersfactuur), in_refund (creditnota leverancier). Dit veld bepaalt welke layout en stroom toegepast worden.


3. state

Type: Selection. Workflowstatus: draft, posted of cancel. In draft kun je wijzigen; posted is vergrendeld en heeft impact op de grootboekrekening; cancel maakt de boeking ongedaan.


4. date

Type: Date. De datum van het document. Belangrijk voor rapportering, verouderingsanalyses en periode-afsluitingen. Voor facturen vaak de factuurdatum.


5. journal_id

Type: Many2one (account.journal). Het journaal waaraan de boeking toegerekend is: verkoop, aankoop, bank of divers. Het journaal bepaalt onder meer de sequence en standaardrekeningen.


6. company_id

Type: Many2one (res.company). Bij multi-company geeft dit aan tot welke vennootschap de boeking behoort. Het beïnvloedt zichtbaarheid en consolidatie.


7. partner_id

Type: Many2one (res.partner). De klant of leverancier. Verplicht voor facturen en bills. Wordt gebruikt voor verouderingsrapporten, matching van betalingen en headerinformatie op documenten.


8. currency_id

Type: Many2one (res.currency). De valuta van de boeking. Bedragen zijn in deze valuta opgeslagen; voor rapporten in groepsvaluta wordt vaak de bedrijfscurrency gebruikt.


9. amount_total

Type: Monetary. Het totale bedrag van de boeking. Voor facturen is dit het te betalen bedrag, berekend uit de regels.


10. amount_residual

Type: Monetary. Het openstaande bedrag. Voor volledig betaalde facturen is dit nul. Van belang voor veroudering en betalingsafhandeling.


11. payment_state

Type: Selection. Betalingsstatus: not_paid, in_payment, paid, partial, reversed, of invoicing_legacy. Stuurt herinneringen en rapporten aan.


12. line_ids

Type: One2many (account.move.line). De journaalregels. Elke regel bevat een rekening, debet en credit. Debet en credit moeten in totaal in balans zijn.


13. invoice_line_ids

Type: One2many (account.move.line). Voor facturen en bills bevatten deze de product- of dienstregels. Bij posten genereert elke regel één of meer journaalregels.


14. invoice_date

Type: Date. De factuurdatum. Relevant voor facturatieperiodes en btw-aangifte. Kan in sommige setups verschillen van de move date.


15. invoice_date_due

Type: Date. De vervaldatum. Gerekend vanuit betalingsvoorwaarden of handmatig ingesteld. Gebruikt voor debiteurenbeheer.


16. ref

Type: Char. Externe referentie, zoals een leveranciernummer. Handig bij matching en afstemming met papieren of e-maildocumenten.


17. invoice_origin

Type: Char. Bron van het document. Bij facturen uit een verkooporder wordt hier bv. het SO-nummer bewaard, zodat je altijd de keten kunt volgen.


18. create_date

Type: Datetime. Tijdstip van aanmaak. Wordt automatisch door Odoo beheerd.


19. write_date

Type: Datetime. Laatste wijzigingsmoment. Ook automatisch bijgehouden.


20. narration

Type: Text. Interne toelichting of memo. Wordt op journaalafdrukken getoond, maar niet op klantfacturen die naar klanten gaan.


21. fiscal_position_id

Type: Many2one (account.fiscal.position). Bepaalt de fiscale positie en welke btw-regels van toepassing zijn, vaak afhankelijk van partner en land.


22. invoice_payment_term_id

Type: Many2one (account.payment.term). Betalingsvoorwaarden (bv. 30 dagen). Wordt gebruikt om invoice_date_due te berekenen en betalingen op te splitsen.


23. invoice_user_id

Type: Many2one (res.users). De verkoper of verantwoordelijke gebruiker. Handig voor commissies en rapportages.


24. reversed_entry_id

Type: Many2one (account.move). Verwijst naar de gecorrigeerde boeking bij reversals, zodat correcties traceerbaar blijven.


25. to_check

Type: Boolean. Vlag voor boekingen die extra controle nodig hebben. Gebruikt in bankafstemming en uitzonderingsworkflows.


26. active

Type: Boolean. Soft-delete vlag. Wanneer False is het record gearchiveerd. Geannuleerde boekingen worden meestal naar inactive gezet.


27. sequence_number

Type: Integer. Het volgnummer uit het journaal. Nuttig voor ordening en weergave; beheerd via het sequence-mixin.


28. amount_untaxed

Type: Monetary. Subtotaal voor belastingen. Bij facturen is dit de som van de regels vóór btw.


29. amount_tax

Type: Monetary. Het totaal aan btw. Wordt berekend uit de factuurregels en het belastingschema.


30. invoice_source_email

Type: Char. Bij leveranciersfacturen die uit e-mail worden ingelezen, wordt hier het afzenderadres bewaard voor automatische verwerking.

Hoe dit model gebruikt wordt in bedrijfsprocessen


1. Klantfacturatie

Bij uitlevering of voltooiing van een verkooporder genereert Odoo een account.move met move_type out_invoice. De invoice_line_ids komen uit de orderregels; posten maakt de bijbehorende journaalregels en actualiseert de debiteuren.


2. Leveranciersfacturen

Aankooporders kunnen facturen aanmaken, of facturen worden manueel ingevoerd. Elke leveranciersfactuur is een account.move met move_type in_invoice; de partner_id is de leverancier en posten verhoogt de te betalen bedragen.


3. Betalingsafstemming

Betalingen worden gekoppeld aan facturen via amount_residual en payment_state. Tijdens reconciliatie worden betalingstransacties verbonden met facturen zodat het openstaande saldo wordt weggewerkt.


4. Handmatige journaalposten

Boekhouders maken entry-type moves voor correcties, accruals of aanpassingen. Zij voegen handmatig line_ids toe met rekeningen, debet en credit. De boeking moet in balans zijn voor het posten.


5. Creditnota's en terugbetalingen

Creditnota's gebruiken move_type out_refund of in_refund en keren de oorspronkelijke factuur of bill om. De reversed_entry_id verwijst terug naar de originele boeking voor auditdoeleinden.

Hoe ontwikkelaars dit model uitbreiden


Ontwikkelaars breiden account.move uit met verschillende patronen; de ingebouwde model-inheritance is daarbij het belangrijkste middel.


Modelinheritance

Gebruik _inherit = 'account.move' om het model uit te breiden. Je kunt nieuwe velden toevoegen, methodes overschrijven of extra constraints invoegen. Door je wijzigingen in een aparte module te houden blijft upgraden eenvoudiger.


Velden toevoegen

Definieer extra velden in je overerven model en kies het juiste veldtype: Char, Many2one, Boolean, Integer, Text of Selection. Denk aan company-dependent velden in multi-company om inconsistenties te vermijden. Voor factuurspecifieke velden kun je een domain op move_type gebruiken.


Python-uitbreidingen

Overschrijf create, write, _post of button_draft om logica toe te voegen, en roep altijd super() aan waar nodig. Let op computed fields en hun dependencies; gebruik de juiste API-decorators (@api.model, @api.depends) zodat methodes op het juiste moment draaien.


Odoo Studio

Met Odoo Studio voeg je snel velden toe zonder code — handig voor eenvoudige extra referenties. Voor complexe validatie of automatiseringen blijft een custom module echter onderhoudbaarder en veiliger.


Belangrijk: account.move is een regulier persistent model, geen abstract of transient model. Abstracte modellen zijn sjablonen zonder eigen database-tabel; transient modellen zijn tijdelijk (wizards). account.move bevat blijvende boekhouddata.

Aanbevolen werkwijzen


  • Filter altijd op move_type bij rapporten of integraties. Elk type heeft eigen verplichte velden en gedragingen.
  • Gebruik voor elk document het juiste journaal. Foutief toegewezen journaals verstoren sequences en rapportering.
  • Wanneer je via de API boekingen aanmaakt: zorg dat line_ids in balans zijn (debet = credit) voor je post. Ongelijke boekingen worden geweigerd.
  • Bij factuurcreatie vanuit externe systemen mappen: zorg dat je documenttypes correct naar move_type vertaalt — out_invoice voor verkoop, in_invoice voor aankoop.
  • Gebruik het x_-prefix voor custom velden om botsingen met toekomstige Odoo-versies te vermijden.

Veelgemaakte fouten


  • Een veelvoorkomende fout is posten van ongebalanceerde regels; Odoo zal de post afwijzen. Controleer altijd dat debet en credit gelijk zijn.
  • Posted moves rechtstreeks wijzigen is een no-go: ze zijn vergrendeld. Maak een reversering en boek een nieuwe correctie in plaats van directe aanpassing.
  • Partner_id vergeten invullen op klant- of leveranciersboekingen veroorzaakt problemen: veel rapporten en workflows verwachten die koppeling.
  • Het verkeerde move_type gebruiken komt vaak voor. Een out_refund is geen negatieve out_invoice — gebruik het juiste type voor creditnota's en terugbetalingen.
  • Core-methodes overschrijven zonder super() te gebruiken kan andere modules en toekomstige upgrades breken. Roep altijd de originele logica aan tenzij je bewust vervangt.

Slotwoord


Het account.move-model vormt het hart van Odoo Accounting: het verenigt facturen, bills en journaalposten in één structuur. Wie de velden en uitbreidingsmogelijkheden begrijpt, kan Odoo beter inrichten, aanpassen en koppelen.


Of je nu processen ontwerpt als consultant of modules bouwt als ontwikkelaar: een stevige kennis van account.move bespaart tijd en voorkomt dure fouten.

Hulp nodig met je Odoo-implementatie?


Dasolo ondersteunt bedrijven bij implementatie, maatwerk en optimalisatie van Odoo. We specialiseren ons in API-koppelingen en development, met diepgaande kennis van de Odoo-datalaag en modellen zoals account.move.

Heb je hulp nodig bij implementatie, custom modules of koppelingen? Wij helpen je graag. Plan een demo om je project te bespreken.

Het account.move-model: Odoo-facturen en journaalposten Begrijpen
Dasolo 10 maart 2026
Deel deze post
Aanmelden om een reactie achter te laten