GL coding suggestion

A GL coding suggestion is a proposed account plus the evidence behind it, not a posted line. Spend platforms such as Ramp or Brex, and ERPs such as Workday or SAP, can show that proposal next to a card charge or an AP invoice. Display is not posting. Accounting still posts.

Treat any code the model returns as a draft on the voucher until a named reviewer accepts it. If import jobs write the proposal straight into the ERP coding field, you skip the control that makes the chart of accounts mean something, and you train the next run on unreviewed output.

Quality for this outcome is narrow. The suggestion must cite the vendor, the memo, and a prior posting. If history is thin, the field stays empty. Do not invent an account so the row looks complete. Empty is a successful result when the packet cannot support a code.

Build a packet for every line before the model sees the invoice. Guessing from a vendor name alone is how neighbor-vendor errors start.

Load the vendor as the ERP stores it: vendor ID and legal name, not the merchant string from a card feed. Map Ramp or Brex merchants to the Workday or SAP vendor master first. If the IDs do not match, you do not have that vendor's history.

Load the memo as it will sit on the voucher. Use the invoice description, PO line text, or card memo after invoice OCR and extraction has already produced text. Coding from an unextracted PDF is not coding from a memo.

Load prior postings for that vendor ID in the same company code: documents that actually posted, with the GL string that hit the ledger. Exclude rejected suggestions and drafts. A suggestion that never posted is not history. Pull history in the same book as the voucher. A posting in another company code, a clearing account, or a reversal is not a cite you want the model to copy.

If the invoice is still in match, wait for three-way match agent status before you treat the line as ready to code. A quantity or price exception is an AP problem, not a reason to pick an expense account. If the spend might capitalize, do not let a subscription-looking memo force an opex account. That decision belongs with the capex vs opex classifier on the same packet, not with a second invented code.

History is thin when there is no posted invoice for this vendor ID in this company code, when the only hits use a different memo pattern (freight versus product, pass-through versus own spend), or when the last posting was a reclass that moved the original code. One stray invoice to a clearing account is not a pattern. Send that packet to the model anyway, and expect a blank.

Every non-empty suggestion must name what it used. Minimum cite: vendor ID and name, the memo excerpt, and one prior posted document (number, date, posted account). A fourth line in plain language helps the reviewer: same vendor, same memo pattern, same account on the last invoices, or new vendor, no posting history.

If the model cannot point to a real prior document for this vendor, return blank. Do not complete a GL string with a default cost center, product, or intercompany segment because the natural account looks right. A fabricated segment is an invented account.

The accountant accepts, rejects, or overrides. Accept copies the proposed code into the voucher draft. Reject leaves the field empty and routes new-vendor coding to the person who owns first invoices. Override records the human code. That override becomes prior history only after it posts. Keep model output out of the posting set until then.

The reviewer should open the cited voucher, confirm the vendor ID, and confirm the memo is the same kind of spend. If the cite does not survive that check, treat the suggestion as blank and code it yourself.

A monthly software invoice arrives for vendor V-4418. Memo reads "Annual seat renewal, analytics platform." Three prior invoices for V-4418 in company 100 posted to 6400 Software subscriptions. The packet contains those three documents, the vendor ID, and the memo. The model proposes 6400 Software subscriptions and cites V-4418, the seat-renewal memo, and the most recent posted voucher. The accountant accepts. History was thick, the memo matched, the cite was a real document.

The following week a reseller invoice arrives. The company has never paid that legal entity. The card merchant string is close to V-4418's DBA. If you retrieve history by fuzzy name instead of vendor ID, the model proposes 6400 from the neighbor's file and the row looks as confident as the monthly renewal. The correct output is empty: new vendor, no posting history. Do not invent 6400 because the memo says analytics. AP sets up the vendor. An accountant codes the first invoice.

That pair is the whole pattern. Repeating vendor with cited postings can suggest. First invoice, or thin history, stays blank.

Coding a new vendor from a neighbor is the failure that survives review because it looks consistent. Similar names, shared parents, and card merchant aliases are not the same vendor ID. If IDs differ, do not copy the neighbor's account. Return blank, then a person codes.

Treating the suggestion as posted is a process failure, not a model failure. Keep the proposal in a side field until someone accepts it. The posted journal still needs the same approver the department already uses for manual coding. If you skip that step, later journal entry anomaly detection may flag the entry, but the books already moved.

Inventing a GL string shows up when history is thin and the row has a required-field check. The model fills an expense account plus a cost center borrowed from other vendors. The form validates. The allocation is fiction. If you cannot cite a prior posting that used that full string for this vendor, leave the entire code empty rather than half-fill it. Incomplete codes that pass a required check are worse than blanks: nobody goes looking for them.

Run the how-to in that order every time. Load vendor, memo, and prior postings. Suggest only with cites. Leave blanks when the trail is thin. Let the accountant accept. New vendors, one-off memos, and first invoices in a new company code stay empty until a person chooses the account. The model does not own the chart.