A Posting Protocol for AI in the General Ledger

The function was short and well intended. In an invoice automation a client had inherited from another supplier, it ran whenever the system detected that one of its own postings was wrong, a wrong cost centre for example. It deleted the entry and posted a corrected one. The ERP allowed this for unpaid documents in an open period, so nothing stopped it.

The ledger it left behind was correct. The history of how the ledger got there was gone. Entries had appeared and disappeared with no trace of why, and it took the finance team weeks to reconstruct which ones had been rewritten. They switched the function off before anyone asked what else it could delete.

Reading documents gets most of the attention in finance automation. Writing to the ledger is where trust is won or lost, and it needs a protocol, not only an integration.

Automated errors go through the human correction process

One rule sits under everything else. When automation makes a mistake in the ledger, it is corrected by the people and the process that correct human mistakes: a reversal or correcting entry raised by the finance team, with a reason and an approver. Never by the system, and never by deletion.

This is not caution for its own sake. The correction process is the part of finance that auditors already test and controllers already trust. An automation that fixes its own entries has created a second correction process, undocumented, with no segregation of duties. So its rights in the ERP exclude deleting, parking or changing documents it has posted. The rule holds even when the code is wrong.

Every posting follows five steps

A business key, not a request ID. Each posting carries a key built from the business identity of what is posted: company code, supplier, the supplier's invoice number, amount. It lives in a reference field the ERP already has, agreed with finance and IT. The same invoice always produces the same key, however often the workflow restarts or retries. Stripe's engineering team explained idempotency keys for payment APIs in 2017. Inside an ERP, the lesson that matters is where the key comes from. A key generated per request protects against a duplicate request. Only a business key protects against the workflow deciding twice.

Check before writing. The workflow asks the ERP whether a document with this key exists, and trusts the ERP's answer over its own memory.

Check the period. If the target period is closed, or inside a cut-off window the controller has defined, nothing is posted and the case goes to a person with a proposed date. Choosing the period for an entry is a judgement about the financial statements. It is not the automation's to make.

Write through the front door. Postings go through the ERP's standard interfaces, so its validation, numbering, tax logic and authorisations apply. Never directly into tables.

Read back and record. After posting, the workflow reads the document back and stores the ERP's document number against the case. Only then is the step complete.

Each posting type inherits a control that already exists

Every audited finance function has a controls framework: key controls, each with an owner and a test the auditors perform every year. The fastest way to make automated postings acceptable is not to invent controls for them. It is to place each posting type inside a control that is already tested.

Before go-live we sit with the controller and the internal control owner and build that mapping. Supplier invoice postings fall under the existing three-way match and approval controls. Accrual proposals fall under the month-end accrual review. Payment proposals fall under payment release, with segregation of duties unchanged. For each, we document what the automation does inside the control and what evidence it leaves for the test.

Where no existing control fits, that is a finding in itself. The automation is doing something finance has never done by hand, and it needs a decision from the control owner, not a clever workaround. The workflow posts under its own named service account, so auditors can sample its entries with the procedures they already use for people's.

Duplicate payments get a second, independent defence

A duplicate posting is an inconvenience. A duplicate payment is money leaving the company.

Supplier invoice numbers are poor identifiers. The same invoice arrives as INV-0042, 42 and 0042, or comes back months later as a reminder with a new scan. So before release for payment, a separate check looks for near-duplicates: same supplier, similar amount, similar date, invoice numbers equal once prefixes, zeros and punctuation are stripped. Matches go to a person even when the business key says the invoice is new. We do not rely on the bank's duplicate checks or the ERP's warning as the only defence. Both help, and both have gaps we have seen in practice.

Payment files have their own rule. Each approved batch produces exactly one file, with an identifier recorded before it leaves. If the transfer fails or its status is unclear, the system never resends. A person checks the bank's status and decides. Resend is the one retry that can cost real money, and the check takes minutes.

The system reconciles its own actions daily

Once a day, a separate process compares what the workflow believes it has written with what the ERP and the bank hold. Every completed case should have exactly one document. Every document carrying the workflow's reference should belong to a case. Every payment in a file should appear once in the bank's confirmation. Differences become exceptions for the finance team, with evidence.

The job is almost always silent, which is the point. When it is not, it finds the problem before the close does. It also answers the auditor's question about automated postings directly: here is every action the system took, and proof that each happened once.

Give it no way to rewrite history

A finance team does not judge automation by how well it reads a PDF. It judges it by whether every entry in the ledger can be explained. An automation that can only add, and whose mistakes are corrected the way people's always have been, can always be explained.