Review an AI invoice draft against the job evidence
Trace proposed invoice lines to their source records. Use a fictional quantity reconciliation and test missing approvals, duplicates and reviewer permissions.
Use AI invoice review to prepare a traceable draft or flag missing evidence. Keep the decision to post, send or collect separate. The reviewer needs to see where each line came from and what remains uncertain.
Odoo's invoicing documentation distinguishes draft creation from validation and sending, and describes several source flows for invoices. That supports treating a draft as a reviewable state. It does not mean a draft prepared by AI is correct or that every connected agent has the right permissions. Odoo 19.0 invoicing processes.
For a first pilot, choose one invoice type with a clear basis for the charge. Compare the agent's proposal against records a person can inspect. Leave missing approvals and disputed quantities unresolved until the authorized reviewer decides.
Give the reviewer the source behind every line
A plausible description and a correct multiplication can still produce the wrong charge. The quantity may have come from material allocated to the job rather than material actually used. An hourly price might have been taken from an old estimate. Extra work might have been discussed without being approved.
Require the proposed line to carry the relevant job or order identifier, source record, source date and reason for inclusion. A reviewer should be able to move from the proposed amount to that evidence without searching an entire conversation history.
Use these columns in the review packet:
| Proposed line | Quantity and unit | Price source | Work or approval evidence | Review decision |
|---|---|---|---|---|
| Description someone can recognize | Explicit, including units | Current agreed basis | A direct record reference | Accept, correct or hold |
Treat “hold” as a useful result. An assistant that identifies an unresolved charge has completed a different, valuable part of the review. Do not force it to finish the invoice by guessing.
Reconcile this fictional service job
The following numbers are illustrative. They are a calculation exercise, not DATUM pricing, customer data or an invoicing policy. Taxes, deposits, discounts and other adjustments are outside the example.
The synthetic records say:
- The agreed labor charge is three hours at $80 per hour.
- Two valves were installed, at an agreed $35 each.
- A third valve was taken to the job and returned unused.
- An additional item was approved at $45, with the approval attached.
The proposed draft includes three valves. The arithmetic is consistent with that wrong quantity:
| Line | Proposed draft | Supported example calculation | Difference |
|---|---|---|---|
| Labor | 3 × $80 = $240 | 3 × $80 = $240 | $0 |
| Valves | 3 × $35 = $105 | 2 × $35 = $70 | $35 |
| Approved additional item | 1 × $45 = $45 | 1 × $45 = $45 | $0 |
| Subtotal | $390 | $355 | $35 |
The correction comes from the material evidence, not from asking the model to check the arithmetic again. Both subtotals are mathematically correct for their inputs.
Now remove the extra-work approval from the test packet. The expected response should change to “approval missing” for that line. It should not invent an approval, silently remove a legitimate charge or declare the whole invoice ready. The reviewer resolves the missing evidence under the company's agreed process.
Check identity before checking amounts
A draft for the wrong job can look internally consistent. Include cases with similar customer names, several properties owned by one customer and a return visit related to an earlier job.
Require the review packet to show the customer, service location, job identifier and source order. If those disagree, hold the proposal before adjusting individual lines. An address copied into the text is not proof that the underlying invoice belongs to the right account.
The same principle applies to duplicates. Give the pilot the same request twice and inspect the saved state. Confirm that repeated processing does not quietly create another draft or another line. Define what should happen when a person edits the draft between the first and second run.
Keep approval attached to the exact draft
A reviewer should approve the values they can see. If quantities, prices or source records change afterward, require the changed proposal to be checked again before the next consequential action.
For an Odoo integration, inspect the permissions of the actual automation user. The documented JSON-2 API enforces that user's rights and record rules; it does not make a broadly privileged account safe merely because the prompt says “draft only.” Odoo 19.0 External JSON-2 API.
A bounded pilot can prepare a separate review packet while leaving posting and sending with the existing billing role. If the pilot writes an Odoo draft directly, test exactly which other actions the same account can perform. Payment execution is outside this pilot.
Review a mixed set of cases
Use a clear job, an approved change, an unapproved change, a returned item, conflicting quantities and a repeated request. Add at least one case whose correct outcome is to ask for evidence.
Record line accuracy, unsupported additions, missed charges, duplicate proposals and reviewer time. Keep corrections distinct from harmless differences in wording. A fluent description does not compensate for an unsupported amount.
Retain the source packet, original proposal and review outcome for each permitted test. That record helps distinguish a bad instruction from missing source data or a permission problem. Fix the responsible part and rerun the failed case alongside a new one.
If the source records do not explain what happened on the job, start with the handoff worksheet. Invoice drafting becomes easier to evaluate when the evidence has a clear owner and place.