WhatsApp us

Blog7 min read29 Oct 2026

How an agent reads supplier bills from Gmail into your books

An agent can read supplier bills from Gmail, extract fields, code them, and queue them for approval. The steps, the checks and what a person still confirms.

How an agent reads supplier bills from Gmail into your books

By KYN AI Advisory Team — AI implementation specialists, Singapore

An agent reads supplier bills from Gmail in five steps: it finds the email, pulls the attachment, extracts the fields, codes the bill to an account, and queues it for a person to approve. Nothing posts to your books until a named person confirms. The agent removes the typing and the chasing of missing bills. It does not remove the decision that a bill is valid and should be paid.

What does the agent do, step by step?

  1. Find. It watches a mailbox or a label for new messages with an attachment or a link that looks like a bill.
  2. Collect. It saves the PDF or image to storage and records the email, sender and time. The original stays as the audit record.
  3. Extract. It reads supplier name, bill number, date, due date, currency, line items, tax and total.
  4. Code. It proposes an expense account and tax code, using the supplier's history.
  5. Queue. It puts the bill in an approval list with the extracted fields beside the original document.

A person approves, edits or rejects. Only then does the bill enter the ledger or go to the accounting package. If you want the same flow for staff receipts, see expense claims by WhatsApp photo.

How does the agent get access to Gmail safely?

Access is the first design decision.

  • Scope. Use a dedicated mailbox, such as a shared bills inbox, or a label that your team applies. Do not grant access to every executive mailbox for a task that needs one.
  • Permission. Use the narrowest read permission available through Google's API. Read-only is enough for collecting bills. The agent does not need to send from this account.
  • Identity. The agent connects with its own restricted account or service credential, not a person's login. Revoking it must not affect any user.
  • Logging. Every message the agent reads is logged with time and the action taken.

The mailbox is the risk surface. A bill email is untrusted input from outside. Text in it must be treated as data, never as an instruction to the agent.

How does it extract fields without making things up?

Extraction is where an agent earns its keep, and where errors enter.

Two rules keep it honest.

  • Cite the source text. For each field the agent returns the text it read. A script confirms that text appears in the document. A field without evidence is marked missing, not guessed.
  • Check the arithmetic in code. Line totals plus tax must equal the bill total. If they differ, the bill is flagged. The model reads the numbers. Code adds them.

Add format checks: the date parses, the currency is on your list, and the bill number is not already in the system. The duplicate check matters most. Suppliers resend bills, and one bill arriving as an email and as a statement attachment should land in your books once.

For the testing method, see hallucination checks for business agents.

How does it decide the account and tax code?

Coding is a proposal, not a decision. The agent uses three sources, in order:

  1. The supplier's history. If the last twelve bills from a supplier went to "Software subscriptions", the thirteenth probably does.
  2. Your chart of accounts and rules. A rule such as "any bill from this supplier with this keyword goes to this account" overrides the history.
  3. Its own reading of the line items, used only when the first two give no answer, and always flagged for review.

Tax coding needs more care. Whether a supplier is GST-registered, whether the purchase is claimable, and whether an overseas service needs reverse charge treatment are accountant questions. We set out the split in GST on bills: what an agent can code and what an accountant must confirm.

What lands in the approval queue?

A good queue shows what a reviewer needs and nothing more.

| Column | Why it is there | |---|---| | Supplier and bill number | Identity and duplicate check | | Amount and currency | The decision | | Due date | When it must be paid | | Proposed account and tax code | The agent's proposal | | Flags | Total mismatch, new supplier, unusual amount | | Original document | One click to the source |

Group by flag. Clean bills from known suppliers can be approved in a batch. New suppliers and amounts far above the supplier's usual range wait for a closer look. The reviewer's time goes to the exceptions.

Approval writes the bill to your books. Payment is a separate step. The agent can list bills due this week, but a named person releases the payment.

What does it cost to run?

Cost depends on bill length and the model. Our own books run on this pattern: bills arrive from Gmail, are read and queued, and receivables are chased on a schedule. Short-text tasks in our live systems cost cents: about S$0.01 to sort a reply and about S$0.03 for a document comparison. Those are KYN's measured figures for other tasks. Measure bill reading on your own volumes during the review.

The larger saving is staff time. A person no longer opens each email, downloads each file or retypes each line. They review a list.

What still needs a person?

  • Approving the bill for payment.
  • Confirming a new supplier's bank details by a second channel. Payment fraud often starts with a changed account number in an email.
  • Tax treatment that is not routine.
  • Disputes, credit notes and partial deliveries.

This matches the approval pattern in setting approval gates for high-risk agent actions.

What does a worked example look like?

Take a services firm that receives 60 supplier bills a month (illustrative). Before the agent, one person opens each email, saves the file, types the fields and codes the account. After the agent, that person reviews a list.

| Bills in the month (illustrative) | Count | What happens | |---|---|---| | Known supplier, totals add up, no flags | 41 | Approved in one batch | | Known supplier, amount well above usual | 6 | Reviewed one by one | | New supplier | 5 | Bank details checked by a second channel | | Total does not add up or field missing | 4 | Corrected by hand or sent back to the supplier | | Duplicate of a bill already in the system | 4 | Rejected automatically, logged |

Two things to notice. The batch of 41 is where the time saving sits. The other 19 are where the control sits, and they reach a person with the reason attached. Track the flag counts each month. If new-supplier flags climb, someone is onboarding suppliers outside your process, and that is worth knowing before it becomes a payment problem.

Where KYN fits

KYN built this for its own books: bills come in from Gmail, and receivables are chased at 3, 14 and 30 days. The same pattern runs in client systems in their own cloud accounts, with named accounts, row-level security and every action logged with the actor. Money and filings wait for a named person.

The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. See finance systems and integrations.

Frequently asked questions

Can an agent post bills to Xero or another package automatically?

It can write a draft bill through the package's API. We keep the final approval with a person. A wrongly posted bill is harder to unwind than a draft is to approve.

What about bills sent as links, not attachments?

The agent can follow a link to a portal download if the portal allows automated access. Many require a login, in which case the bill is flagged and a person fetches it.

Does it work for bills in other languages or currencies?

Yes, with a test first. Run a sample of your Bahasa Indonesia, Chinese or English bills through the golden-set check, and record the original currency. Conversion rates should come from a fixed source you choose, so the same bill always converts the same way.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →

Written 29 Oct 2026 · Checked 29 Oct 2026