Deterministic coding
Decide the accounting
the same way every time
GL account, class and department are decided by your rules, the same way every time.
3+
segments resolved independently on every line
0
model calls at posting time
1
method recorded per resolved segment
3
recurrences before a fix is offered as policy
How a line is coded
Several decisions,
not one
Segment by segment
GL, class and department each follow their own logic on the same line. Each is answered by one of: a fixed value for the vendor, a lookup on a signal read off the invoice, a project map, a keyword match, or the line itself.
Signals, wherever they are printed
One vendor puts the cost centre in a customer-id field, another in the description, another only on the remittance page. Signal lookups read it wherever that vendor prints it.
A watchlist, not a guess
An uncategorised product is flagged rather than silently miscoded. Unknown vendors are left alone. PO invoices take GL, class and department straight from the purchase order.
Lookup tables
Your lookups, imported from what you already have
Lookup tables import from Excel, CSV or pasted text. The system proposes the column mapping, a person confirms it, and every produced value is validated against the live chart of accounts before it can be used.
- Client-maintained — no developer in the loop
- Validated against the live chart of accounts
- Header and posting-field rules: memo, department, dates, custom posting fields, with per-vendor exceptions
“Code Globex lines to 600200 and the site named in the description. If the line mentions security, use 600250 instead.”
Correction learning
Your corrections compound
A clerk fixes a line and chooses “this invoice only” or “this rule”. When the same vendor and signal correction recurs — three times by default — it is surfaced as a suggested rule promotion for an approver. The fix becomes policy deliberately, not silently.
- Approver in control of what becomes policy
- Every promotion versioned with rollback
- Coding diagnostics compare against the bill as it actually posted and name the cause of any difference
Coding,
answered
The model writes rule code once, at authoring time, and you see the logic in plain language before approving it. At posting time an approved rule runs in a restricted sandbox — no imports, no network, no filesystem, no clock, no randomness. The same input produces the same output.
Those are extra segments with their own logic, resolved the same way. Client-defined custom posting fields each get a global default and per-vendor exceptions.
Upload the bill as it was actually posted. Coding diagnostics compare line by line and name the cause: no rule for this vendor, the signal was not read off the page, no lookup row, the lookup maps elsewhere, or the rule and lookup disagree.
Stop re-deciding the same coding
Bring one vendor whose invoices are hard to code. We will write the rule with you and backtest it against their history.