Invoice approval: context that reaches the accountant

An invoice rarely reaches the accountant carrying everything the accountant needs. The document says what was bought and for how much. It does not say which site or project it was for, that part of the amount is disputed, or that a later payment date was agreed with the supplier. The person who ordered it knows all of that. And usually they say it on the phone — two weeks later, when the accountant finally asks.

The questions that travel by phone

The usual sequence: an employee forwards an invoice, the accountant opens it, something does not make sense, and a message goes out. The answer comes back verbally or in a separate email, and nothing at all is left on the invoice itself. A month later, when a manager or an auditor asks why this invoice was split the way it was, the answer lives in somebody's memory.

The problem is not that people fail to talk to each other. The problem is that the context and the document live in different places, so the same question gets asked again from scratch — and costs two people's time every time.

A note needs an author and a timestamp

A single shared notes field looks like a solution right up until two people touch the same invoice. The second one writes their sentence over the first, and now neither what was written before nor who wrote it exists any more.

So notes are a thread, not a field. Every entry carries an author and a time, older entries stay visible, and the accountant reads the whole conversation on the invoice itself — not across two emails and one phone call. Notes stay internal: they never travel into the accounting system or into the VAT register, because they are working papers, not an accounting record.

"Please pay by" is a request, not an instruction

The printed payment term is not always the one the invoice is actually paid on. A later date was agreed with the supplier, part of the amount is disputed, the delivery has not been accepted yet. The person who knows that can attach a requested pay-by date to the invoice, and the thread records who asked for what without anyone having to write it out.

The important part is that it stays a request. Nothing changes the invoice's payment term on the accountant's behalf: they see the request, they see who made it, and they apply it or ignore it in one click. The term printed on the document is what the document says; departing from it is the accountant's call, not a colleague's.

The split is made by the person who knows how

The most common reason a line does not fit one analytics code: a single supplier line — materials, fuel, haulage — covers several sites or projects. Until now the only person who could split that line was the accountant, and the only person who knew the proportions was whoever ordered it. Between them sat a phone call.

Now the submitter can split the line too — in the same place where they fill in dimensions, using the same dialog the accountant uses. Each part gets its own project or department. The amount does not move: the parts add up to exactly the line total printed on the document.

Splitting is possible until the accountant has taken the invoice into work and it has gone across to the accounting system. After that the lines may already be posted there, so they lock — the same window that governs dimension edits.

When there are more lines than the PDF prints

Splitting has one side effect that looks like a fault if nobody explains it: the document prints one line and the screen shows three. An accountant who is not expecting that assumes the invoice was read badly, and starts checking something that is entirely correct.

So every line produced that way is marked as split, and the history shows who split it and when. The difference between "the system read this wrong" and "a colleague allocated it across sites" has to be visible at a glance, not explained afterwards.

The approver can see the employee is not finished

The second mistake nobody catches in time: an invoice gets approved before the person who submitted it has finished filling it in. To the approver the list looks the same either way — a row is a row, and the required dimensions behind it are empty.

Now the row says the employee has not confirmed it yet, and names which required fields are still missing — each one named once, not once for every line it is empty on. Unconfirmed submissions can be filtered out on their own, and approving several at a time shows how many of them are unfinished. Approving anyway is still allowed: the decision stays with the person, it is just now made knowingly.

What this changes at month-end

• •The question loop gets shorter: context arrives with the document instead of two weeks later
• •Analytics gets filled in where it is known, rather than where it has to be guessed
• •Month-end close no longer opens with phone calls about last month's invoices
• •Every explanation has an author, so six months on nobody has to remember anything

Where to start

You need nothing you do not already have: the same projects or departments you already use in your accounts, and an agreement about who fills in what. In practice a short rule is enough — the submitter enters the site and explains what the document does not say; the approver says yes or no; the accountant codes it and sends it across. For people who only forward invoices from their mailbox and have no account in the system, nothing changes: their invoices get explained by whoever approves them.

Frequently asked questions

Do notes end up in the accounting system? No. They are internal working papers. They stay with the invoice and never travel into an export or into the VAT register.

Can an employee break the amounts? Splitting a line does not change the amount — the parts add up to the same total, and the action stays in the history with its author. Once the invoice has gone to the accounting system, the lines no longer change.

Does this work when several different people submit invoices? Yes — that is exactly why the thread carries authors. Notes from several people on one invoice do not blend together and do not overwrite each other.