# Deterministic coding | InvoiceIQ by Analytos

> GL account, class and department are each resolved independently by rules your team owns — a fixed value, a signal lookup, a project map, a keyword, or the…

Canonical URL: https://invoiceiq.analytos.ai/features/coding

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.

[Book a walkthrough](https://invoiceiq.analytos.ai/contact)[Rules in plain English](https://invoiceiq.analytos.ai/features/rules)

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

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.

[Book a walkthrough](https://invoiceiq.analytos.ai/contact)

More of the platform

[Document readingEvery line read from a text PDF or a scan, with where it came from on the page.](https://invoiceiq.analytos.ai/features/document-reading)

[Rules in plain EnglishWritten in a sentence, backtested on your history before going live.](https://invoiceiq.analytos.ai/features/rules)

[Inbox & postingExactly-once email intake, a shared queue, a log of every posting.](https://invoiceiq.analytos.ai/features/inbox-and-posting)