How I automated my accounting: receipt to bookkeeping in 3 seconds

The receipt pile

I run a Norwegian AS (limited company). That means I need proper accounting. Every receipt needs to be matched to a bank transaction, assigned the correct account code from the Norwegian kontoplan, and filed correctly. Miss a receipt and your accountant will ask about it. Assign the wrong account code and your tax filing gets messy.

Like most small business owners, I had a system: take a photo of the receipt, email it to myself, and deal with it "later." Later usually meant a Sunday evening before a VAT filing deadline, going through 40 receipts in a pile while trying to remember what a 489 NOK charge at "REMA 1000 TORSHOV" was for. It was groceries. It's always groceries.

I wanted something better. Take a photo, drop it in a Slack channel, and have the AI figure out the rest.

The pipeline

The system I built has five moving parts:

1. Slack channel (#ai-receipts) -- where I drop receipt photos
2. Budsy (Budget agent) -- reads the receipt using AI vision
3. Folio agent -- matches the receipt to a bank transaction in Folio
4. Folio API -- the actual connection to my bank and accounting
5. Fiken -- Norwegian cloud accounting software where bookings land

Here's what happens when I photograph a receipt at a restaurant and post it to Slack:

The Budsy agent picks up the image. It sends the photo to GPT-4o-mini's vision model, which reads the receipt and extracts structured data: vendor name, date, total amount, currency, VAT amount, and individual line items if they're legible. This takes about 2 seconds.

Budsy packages this into a structured message and forwards it to the Folio agent via sessions_send (OpenClaw's inter-agent communication). The payload looks like this:

{
  "amount": 489.00,
  "currency": "NOK",
  "vendor": "Rema 1000",
  "date": "2026-02-25",
  "vat": 97.80,
  "file_path": "/path/to/receipt.jpg",
  "source": "budget"
}

The Folio agent takes this data and queries the Folio API for bank transactions around that date and amount. Folio is a Norwegian fintech platform that connects to your bank account, so it has all your transactions. The agent queries a date window of plus or minus one day and looks for an amount match.

If it finds an exact match (same amount, same date range, merchant name contains the vendor), it attaches the receipt file to the transaction using Folio's MCP server. Then it suggests account codes based on the Norwegian kontoplan.

The whole thing takes about 3 seconds from photo to matched transaction.

The Folio MCP integration

MCP (Model Context Protocol) is how AI agents interact with external tools. Instead of writing custom API code for every integration, you expose tools through an MCP server that the agent can call naturally.

The Folio MCP server runs as a binary at ~/bin/folio-mcp. It exposes 16 tools that interact with Folio's API. The ones Folio agent actually uses:

• get_activities -- fetch transactions by date range
• get_activity -- look up a single transaction
• upload_receipt -- attach a receipt file to a transaction
• set_activity_complete -- mark a transaction as handled

The receipt upload works through Folio's REST API. The MCP server accepts base64-encoded file content, handles the Content-Type and Content-Disposition headers, and POSTs to /v2/events/{eventId}/attachments. It accepts JPEG, PNG, and PDF.

I didn't build this MCP server from scratch. I forked an existing open-source Folio MCP server and added the receipt upload functionality, which wasn't in the original. The Folio API documentation for uploads is sparse. It took some trial and error to figure out that it expects raw binary in the body rather than multipart form data.

The account code suggestion engine

This is where the Norwegian-specific stuff gets interesting.

The Norwegian kontoplan (chart of accounts) has thousands of account codes. A grocery receipt goes to 7140 (Representasjon, deductible) or 7160 (Ikke fradragsberettiget representasjon) depending on whether it was a business meal with a client or just lunch for yourself. A software subscription goes to 6940 (IT-kostnader). Office supplies go to 6800.

Budsy has a three-signal suggestion engine for account codes:

Signal 1: Receipt line items. GPT-4o-mini extracts line items from the receipt. If it reads "Software License: Figma" on a receipt, the system maps that to 6940.

Signal 2: Description keywords. The vendor name and transaction description get matched against keyword patterns. "Rema," "Kiwi," "Coop" all map to grocery-related codes.

Signal 3: Vendor history. If I've booked transactions from this vendor before, the system remembers which account code I used last time. This is stored in a vendor_account_mappings table that learns from every booking I make.

When all three signals agree, the confidence is high and the system shows a green suggestion. When they disagree, it shows the options and lets me pick. The system never auto-creates a booking without my approval. I'll explain why.

The confidence threshold

This is the part where I have strong opinions.

When you build AI automation for financial data, the temptation is to go fully automatic. The AI reads the receipt, finds the transaction, picks the account code, creates the booking. No human in the loop. Maximum efficiency.

Don't do this.

I set a hard rule: the Folio agent can match a receipt to a transaction automatically, but it cannot create a Fiken booking without my explicit approval. The UI shows me the suggestion with all three signals, and I tap "Book this" to confirm.

Why? Because a wrong booking in your accounting isn't like a wrong email label. You can relabel an email in two clicks. A wrong booking might not surface until your accountant reviews the quarterly VAT filing, at which point you're explaining to Skatteetaten (the Norwegian Tax Authority) why you deducted a personal dinner as a business expense.

The AI gets it right maybe 90% of the time. That sounds good until you realize 10% of your bookings are wrong, and wrong bookings in accounting have real consequences.

So: AI suggests, human approves. Every time. The 2 seconds it takes me to tap "Book this" is worth the peace of mind.

The Fiken connection

Fiken is where the actual bookkeeping lives. It's a Norwegian cloud accounting service that small businesses use, and it has a solid API.

The Fiken integration is less mature than the Folio side. Right now, Budsy handles the Fiken POST to /purchases with the structured data. The payload includes vendor, amount, date, VAT, account codes, and a link to the receipt. Fiken creates the purchase record and it shows up in my accounting immediately.

The Fiken API is well-documented, which made the integration straightforward. The Norwegian-specific parts (MVA codes, kontoplan mapping, deduction rules) were the harder problem. The API is easy. Knowing that a coffee meeting with a client is deductible at 100% but a team lunch is only deductible at a different rate, that's the kind of knowledge you need to encode carefully.

I've seeded 31 of the most common account codes into the system. Everything from 3000 (Salgsinntekt) to 7770 (Bank/kortgebyr). That covers 95% of my transactions. For the rare edge cases, I can manually select an account code or add a new one.

What works well

The receipt-to-match pipeline is fast and reliable. I've processed about 50 receipts through this system and the matching accuracy is above 95%. When the amount and date match a bank transaction, it's almost always the right one.

The vendor learning loop is surprisingly effective. After booking three receipts from the same SaaS vendor, the system nails the account code suggestion every time for that vendor.

Multi-currency handling works. I had receipts from a trip in euros, and the system correctly converted the amounts using the bank's exchange rate from Folio (the bank transaction is already in NOK), then matched them.

What still needs work

The receipt OCR isn't perfect on crumpled or low-contrast receipts. Thermal paper receipts that have started fading are the worst. GPT-4o-mini's vision model handles most receipts well, but about 5% come back with wrong amounts or dates. I always verify the extracted data before approving.

Duplicate detection is basic. If I accidentally drop the same receipt twice, the system will try to match it to a transaction that's already been matched. I need to add a check that flags duplicates before processing.

The Fiken integration doesn't yet handle credit notes or refunds well. A return generates a negative transaction that needs special handling in the kontoplan, and the suggestion engine doesn't account for this yet.

Building this for your own setup

The architecture is transferable even if you don't use Fiken or Folio. The pattern is:

1. Intake: a simple channel where you drop receipts (Slack, email, a web form)
2. Extraction: an AI vision model that reads the receipt (GPT-4o, Claude, Gemini)
3. Matching: connect to your bank/accounting system and find the corresponding transaction
4. Suggestion: use vendor history and item classification to suggest account codes
5. Approval: human reviews and approves before any booking is created
6. Learning: store the approved booking to improve future suggestions

The key principle: keep the human in the loop for the financial decision, and automate everything around it. The AI does the tedious work of reading receipts, matching amounts, and suggesting codes. You do the 2-second approval that keeps your accounting clean.

For the Norwegian-specific parts, the kontoplan is publicly available. The MVA (VAT) rates are standard. The hard part isn't the data, it's knowing which code to use for which expense. And that's exactly what the vendor learning loop handles: you teach the system by doing your bookings, and it remembers for next time.

Is it worth it? I used to spend about 2 hours per month processing receipts. Now I spend maybe 15 minutes. Most of that is the approval step, which is just reviewing suggestions and tapping "Book this." For a solo founder running an AS, that's significant time back.

It's not fully automated. That's the point. The boring part is automated. The judgment part stays with me.