Invoices show as approved and validated, and their accounting does not appear in the GL.
Approval is the wrong thing to look at, and that is why this costs a day. Approval is a workflow state about authority — who said yes. Accounting is a separate pipeline about whether the entry can be created at all. An invoice can be fully approved and permanently unaccountable, and nothing on the approval screen hints at it.
Five states, in order. Find the one the invoice reached.
- Validated. Validation is what creates the distributions, so with none there is nothing to account and every later step is vacuous. When validation itself fails the invoice usually carries a hold placed by validation — the one that comes up most often is a distribution variance, where the line total does not match the distributions, usually a tax line nobody expected, though any validation hold stops it here. A hold is visible, which makes this the cheapest state to rule out.
- Accounted. The step that fails most often, with two sub-cases that look identical on the invoice and have different fixes. Draft accounting produces reviewable entries — review is what draft is for — and it is the final run that carries them onward; somebody seeing entries and concluding it worked is the commonest false finish. A real accounting error is the other: an account combination disabled or end-dated after the invoice was entered, a cross-validation rule, or the subledger period closing between approval and accounting. Run Create Accounting and read the output of that run rather than the invoice.
- In the ledger. Do not assume there is a separate transfer step to go looking for. On many configurations running Create Accounting in final is what puts the entries in the ledger, so the useful question is whether they are there — not which process put them there.
- Posted. A journal sits in the ledger without moving balances until it is posted. If the journal is there and the balance has not moved, posting is the step to look at — how posting is triggered varies by configuration, so check how your ledger is set up rather than assuming it happens on its own.
- Visible in the report. The state most people discover the hard way, and the one none of the four above would show. Posting refreshes balances, but a hierarchy change needs the reporting cube published, so a new account can be missing from a report even though its journal posted. The sibling trap is the amount type — period activity, year to date, project to date — which produces plausible but wrong numbers when it is wrong, and nobody checks a number that looks about right.
Establishing which state the invoice reached tells you what to fix. Skipping to the last one is what makes this take a day instead of ten minutes.
The two period statuses are not the same thing
The subledger period and the general ledger period close independently, and the symptom differs by which one is shut. A closed subledger period stops the accounting being created at all, so the invoice never leaves state 2. A closed GL period lets the accounting exist and stops it reaching the ledger or moving balances there. Check both, separately — assuming one status covers both is among the most common confusions on this problem.
Common specifics
- A period that closed between approval and accounting.
- An account combination disabled or end-dated after the invoice was entered.
- A scheduled process that has been failing quietly — worth checking its run history rather than assuming it ran.
What to capture before raising a ticket
The invoice number, which of the five states it reached, the Create Accounting output for that run, and both period statuses. That list is the difference between a two-day thread and one reply.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.