Gains:
- Ability to convert free text and invoice data into a table structured according to a fixed schema
- Ability to set up repeatable prompts for expense categorization, VAT back calculation and anomaly detection
- Ability to verify extracted financial fields with VAT equality and total consistency checks
One of the tasks that accounting teams spend the most time on is organizing scattered expense and invoice data into organized tables. An invoice attached to an email, a photo of a receipt sent from WhatsApp, a free-text expense note like "Ankara meeting meal + taxi 840 TL"... They should all end up in the same place: a line structured with categories, amount, VAT (Value Added Tax), date and supplier fields.
Artificial intelligence (AI) is very powerful in this “free text to structure” transformation. But in financial data, it is unacceptable for even a penny to go wrong. So in this unit we will learn two things together: making AI produce data according to a fixed schema (predetermined list of fields) and validating the output with aggregate consistency checks.
Why Is "Schema" So Important?
Schema is when you tell in advance which fields will be in each row, in what order and in what format. If you do not provide a schema, the model produces a different format for each invoice; Then combining them into a single table would be difficult without correcting manually. If you provide a schema, the output will be both consistent and verifiable.
A good expense chart includes the following fields: date, supplier, description, category, VAT exclusion amount (base), VAT rate, VAT amount, total including VAT, document no.
Tip: Always define numeric fields with the "period/comma" convention. Saying "Write the amounts in the format 1234.56, without the thousands separator" will avoid hours of formatting nightmare when exporting to Excel later.
Step by Step: From Free Text to Table
- Fix the scheme. Write the field names, order and format.
- Give the category list. Ask the model to choose from your list, not to make up categories in her head.
- Make an uncertainty rule. Let him leave the area he is not sure about blank and put a "check" sign.
- Verify VAT logic. Have the model check the equation base + VAT = total.
- Cross check the total. Does the total of all lines match your checksum?
Weak Prompt / Strong Prompt
Weak prompt: Turn the following expenses into a table: - Ankara food taxi 840 - stationery 300 including VAT - hotel 2 nights 3600
This gives an output with category inconsistent, VAT mixed up, format different on each line.
Powerful prompt:Convert the following free text charges into a table EXACTLY according to this scheme:Fields (in this order): date | supplier | description | category |base | vat_rate | vat_amount | total | noteRules:- Category only from the following list: [Travel, Accommodation, Food, Stationery, Transportation, Other]- Write the amounts in the format 1234.56 (no thousands separator).- If "VAT included" is stated, calculate the base and VAT back; If you do not know the VAT rate, write "rate confirmation" in the note field and leave it blank. - Provide the equality of tax base + VAT_amount = total in each line; If it does not provide it, write "DOES NOT MEET" in the note field. - Leave the field you are not sure about, add "check" to the note.
This prompt calculates back the base for stationery including VAT to 250 and VAT to 50, flags items with ambiguous rates and produces a clean output that can be combined into a single table.
VAT Back Calculation Logic
Finding the tax base from an amount including VAT is a frequently required procedure in accounting. Formula: base = total / (1 + rate). For example, for 300 TL including 20% VAT, the base = 300 / 1.20 = 250, VAT = 50. If you explicitly give this formula to the model, the margin of error decreases.
transaction
formula
Sample (20%)
VAT excluded → included
total = base × (1 + rate)
250 × 1.20 = 300
VAT included → base
base = total / (1 + rate)
300 / 1.20 = 250
VAT amount
vat = total − base
300 − 250 = 50
control
base + vat = total
250 + 50 = 300
Working with Invoice Photo and OCR Printout
Expenses from the field often arrive as a receipt photo or PDF invoice. The technology that extracts text from these images is called OCR (Optical Character Recognition). Visual AI tools can do the job, but the OCR output is always flawed: a comma may be read as a dot, "5" may be confused with an "S", a digit of the amount may be lost. Therefore, never include amounts from OCR directly in accounting.
Extract the following fields from this invoice image and write them EXACTLY into the following schema:date | supplier | tax_no | base | vat_rate | vat_amount | totalRules:- Write "UNREAD" in any field you cannot read or are not sure about, do not guess.- base + vat_amount = check total; If not, mark "CHECK". - Give the amounts in the format 1234.56.
It is a critical safety rule not to make anyone guess the uncertain area. If the model completes a number with “most likely to,” the record silently enters the error. The "UNREAD" flag allows the human to go back to the original document and confirm it.
Tip: In the OCR printout, the total amount is usually the most reliable field to read because it is written in large font. If the tax base + VAT = total equation does not hold, you can find in which area the error is by going back from this equation.
Anomaly and Duplicate Record Detection
AI doesn't just translate; It also finds suspicious items. For example, nearly the same amount from the same supplier twice on the same day, or an unusually large expense for the category.
In the expense table below, mark the following anomalies and write the reason:1) Possible duplicate record (same supplier + similar amount + recent date)2) Amounts greater than 3 times the category average3) VAT rate different from the expected for the categoryJust mark and write the reason; do not delete or change any rows.
Caution: The AI's "this may be repetitive" warning is a hint, not a decision. The two records may actually be two different services. The decision to delete or merge is always made by humans; The model just catches your attention.
Mini Cases
Case 1 — Stack of 300 chips. An accounting expert converted a 300-line free-text month-end expense list into a table in about 15 minutes with the diagram prompt. The job, which took 4 hours when done manually, was reduced to 40 minutes with verification. The gain is not just speed; category consistency also increased.
Case 2 — Caught double payment. The anomaly prompt flagged that an invoice of 4,720 TL to a supplier was entered twice with two different document numbers. The examination showed that one was a draft and the other was a finalized invoice, and both were due for payment. Without AI, there would be double payment.
Case 3 — VAT rate trap. The model assigned 20% VAT to the purchase of a staple food; whereas the item was in the lower rate group. Thanks to the "rate confirmation" rule, the line was marked, verified and corrected by the expert source. Lesson: Don't leave the VAT rate to the model, confirm it from the list or document.
Common mistakes
- Translating data without providing a schema. Each line comes in a different format, combining requires manual correction.
- Not providing the category list. The model fits its own categories; reporting becomes inconsistent.
- Not having VAT equality checked. tax base + vat = rows that do not add up to the total are silently entered into the table.
- Mistaking an anomaly warning for a decision. "May be repeated" is a start; The human being makes the decision to delete.
- Skipping the checksum. Relying on the output without comparing the total of the rows to a known control amount.
In summary
- When processing free text expense/invoice data with AI, the most reliable way is to request the output according to a fixed schema.
- Providing a list of categories and clarifying formatting rules (period/comma, thousands separator) keeps the output consistent and transferable.
- Explicitly give the VAT back calculation formula to the model and check the equality of tax base + VAT = total in each line.
- AI is powerful at flagging duplicate and anomalous records, but the decision to delete/merge is always made by the human.
- Cross-validating the line totals with a known checksum secures the entire job.
Application task
Prepare a mixed list of expenses (actual or sample) of at least 10 lines; knowingly include a duplicate entry and an item with the wrong VAT rate. Convert it to a table with the powerful prompt template, then run the anomaly prompt. Check if the model catches the two traps you set and manually verify the VAT equality in three rows.
checklist
- [ ] I defined a fixed schema with field names, order and format.
- [ ] I gave the category list to the model, I did not let it make up.
- [ ] I added the numeric format (period/comma, no thousands separator) rule.
- I checked the [ ] tax base + VAT = total equality.
- [ ] I had an anomaly/duplicate scan done and made the decisions as a human.
- [ ] I compared the row total to a known checksum.