The bill is dated December. The books closed in December.
It arrives in the second week of January, for work done before Christmas, and it has to land somewhere. Whoever is posting it has three real options, reopen the period, post it into January as a deliberate prior-period adjustment, or accrue it, and one unreal one, which is to change the date until the entry is accepted. The unreal option takes four seconds and leaves no note. The other three require someone senior enough to choose, which is why the bill sits in a pile until the pile is the problem.
"Pay" means the payment is recorded in Odoo. Nothing here moves money out of a bank account, and the run is capped.
What you get with AP bill posting
Vendor bills on the same ledger as the purchase orders they came from. A bill can be raised from the order it belongs to, matched line by line against that order on a single screen, and posted to the general ledger without anyone re-typing a figure that already exists in the system. Period control is real: Odoo holds a set of lock dates, fiscal year, tax, sales, purchases and a hard lock, rather than a single switch. Payment terms carry early-payment discount dates and balances, and bills can be set to auto-post per company or per vendor once a person has decided that vendor is safe to auto-post.
Where AP bill posting comes from
Odoo Community, and nothing needs adding. Vendor bills, purchase orders and period control are all in the stock image, no module to add, no tier to reach, no per-user fee, and the deployment is yours. NetSuite bills AP automation as part of the suite you renew per user; in Odoo it is already in the box, and that difference is the product.
One thing is honestly not there, and it is the step before this one. Stock Community has no document-reading capture: no OCR model, no extraction field on a bill, nothing that turns a PDF into a draft. Bills are keyed, or they arrive through the email alias as an attachment that stays an attachment. This page is about what happens to a bill once it exists in the system, and it does not claim to be about how it got there.
What the agent adds to AP bill posting
It checks the period before it posts. Given a batch of draft supplier bills it posts them to the general ledger one at a time, and when a bill belongs to a period that is already closed it stops, names which period the document belongs to and which one is open, gives the options, and waits for a person. It does not move the date to make the entry land.
Five write steps, five approvals. Confirm, receive, bill, post, pay, nothing passes a gate without an explicit yes, and it re-reads the orders from Odoo at each step rather than working from a snapshot it took at the start. When it finishes it writes its own check and runs it on camera: posted count against approved count, no double-writes, totals reconciled.
"Pay" means the payment is recorded in Odoo. Nothing here moves money out of a bank account, and the run is capped.
One batch, one gate. Everything clean posts; what disagrees is held and named.
Illustrative of the built demo, on seeded data. del.ai has completed no customer migrations.
What does it mean to post a supplier bill?
Posting a supplier bill is the step that turns it from a draft record into a journal entry in the general ledger. Before posting, a bill is a document someone has keyed in: it can be edited, corrected or deleted, and it affects no reported figure. Posting writes the debits and credits, the expense or the asset on one side, the payable to the vendor on the other, against a specific accounting date, and from that moment the bill is part of the period's numbers and part of what the vendor is owed. This is why the accounting date on a bill matters more than it looks: it decides which month carries the cost, and it is chosen at the moment of posting rather than by the date printed on the vendor's paperwork.
Why do late vendor bills cause problems at month end?
Because the work happened in one period and the paperwork arrives in the next, and the two facts point at different months. A bill for December services that lands in mid-January has to be recognised in December to make December's numbers honest, but December may already be closed by the time anyone can post it. Every correct answer to that, reopening the period, posting to the open month as a labelled prior-period adjustment, or accruing the cost in December and clearing the accrual when the bill arrives, is a deliberate decision with a consequence for how the two months compare. The incorrect answer, changing the transaction date until the entry is accepted, is faster than all of them and leaves nothing behind to show it happened. That asymmetry, not the volume of bills, is what makes late invoices a close problem.
What should an accounting agent do when the period it needs to post into is already closed?
It should stop and hand the decision to a person, rather than move the transaction date forward until the entry is accepted. Changing the date is the path of least resistance and it is almost always wrong, because it silently restates when something happened in order to solve a problem about where it can be filed. The correct outcomes, reopen the period, post to the open period as a deliberate prior-period adjustment, or accrue it, are different decisions with different consequences, and the person accountable for the close is the one who should be choosing between them. The useful behaviour is narrow and specific: name which period the document belongs to, name which period is open, state the options, and write nothing until someone answers. Oracle describes the opposite instinct on NetSuite's own accounts payable page, where the promise is that "automated journal entries eliminate the need to manually enter debits and credits". Removing the keying is worth having. Removing the moment where a person decides which period a cost belongs to is a different thing wearing the same words.
Can a vendor bill be posted automatically, and when should it not be?
Yes, and the distinction worth holding is between auto-posting a bill and auto-deciding one. Auto-posting suits a bill that is genuinely routine: a fixed monthly charge from a known vendor at a known amount against a known account, where the only human contribution was clicking the button. It suits nothing else. A bill is not routine if it prices differently from the order it came from, if the goods it bills for were not received, if it duplicates one already in the system, or if its date falls into a period that is closed, and each of those is a case where speed is the whole problem, because the error is cheap to catch now and expensive to unwind after payment. The right shape is per-vendor rather than global: decide which vendors are safe to post without reading, and keep everyone else in front of a person.