Auditors depend on finance for access and evidence.
16 tracker items · Controller’s top concern
Appfjord: priorities and a practical quick win
Finance pain points and priorities
Four opportunities
Grouped by pain-theme priority. Delivery sequence follows readiness.
| Opportunity | Evidence | Field-fixable or Light platform team? | Expected impact |
|---|---|---|---|
| 1. Auditor access and evidence | Controller’s top concern; T-06–11. | Field: configure available read-only access and build an evidence pack from approval records and supporting documents. Platform: validate existing tickets before scheduling. | Fewer requests routed through finance; less audit preparation. |
| 2. Vendor tax-reporting data | Head of Tax; T-03. | Field: build a checker that lists missing vendor tax information, tracks cleanup with the tax team, and exports completed records for review. Platform: validate T-03 before scheduling. | Less manual checking and fewer last-minute reporting gaps. |
| 3. Expense VAT treatment | Controller; T-01. | Field: build a checker that applies tax-approved rules to Swedish meal expenses, identifies missing information and flags uncertain cases for review. Platform: T-01 marked “coming soon”. | Fewer repetitive VAT decisions and clearer exceptions. |
| 4. Revenue and tax reconciliation | Manual Stripe posting; GL/Sphere mismatch; T-14/T-30. | Field: build an agent beside Light that compares Stripe revenue and tax with Light postings and Sphere reports, flags differences and helps investigate them. Keep calculations rule-based and accountant review mandatory. Platform: none identified. | Less manual reconciliation and fewer unexplained revenue or tax balances. |
First 60 days
| When | What I would do |
|---|---|
| Monday | Agree priorities with the controller and tax lead. Check live payment blockers. |
| Tuesday–Wednesday | Test auditor access. Trace one Stripe-to-Light-to-Sphere cycle. Sample vendor and expense data. |
| Thursday–Friday | Measure manual effort. Agree success measures, pilot scope and Light dependencies. |
| Days 8–30 | Improve audit access where possible. Pilot revenue reconciliation. Confirm whether vendor-data and VAT work justify a build. |
| Days 31–60 | Test on fresh data, measure results and hand over processes. Deliver validated tax fixes; escalate platform gaps. |
Stop signals
Audit: existing roles solve the problem → configure, don’t build.
Revenue: source totals cannot be verified → fix the data before automating.
Tax: samples show little manual effort, no reporting gap or no approved rules → drop or pause.
Not in the first 60 days
Replace the close tool or rebuild payment rails: too broad; fix selected gaps first.
Automate postings, filings or payments without approval: adds control risk.
General UI, mobile, integration or backlog cleanup: distracts from agreed outcomes.
Reopen closed tickets or clean all historical data: require recurring failures or material differences.
Build shadow ledgers or duplicate access controls: creates another system to maintain.
1 / 3
Expense tax review
Checks expense details against decision rules, classifies complete routine cases, and flags missing information or uncertain cases for finance review.
Synthetic data and illustrative routing rules. This demo checks readiness for tax assessment; it does not determine recoverability or approve tax treatment.
30 synthetic expenses · 5 entities · Cards, reimbursements and AP
Download the sample CSV, edit its rows, then upload and run. Keep column names and value formats unchanged. Files stay in your browser.
Ready to run.
Automatically classified means routed to an assessment category, not tax-approved.
| Expense | Entity | Category | Net / tax | Result / reason |
|---|
Rules & limitations
Demo-v1: missing evidence, mixed use, meals, unsupported profiles or foreign tax route to review. Complete domestic office-supply records are ready for local assessment. Zero-tax software records are classified as no charged tax; self-assessment remains unresolved. Other cases route to review. Amounts do not represent actual tax rates. No data leaves your browser.
Next: tax-approved local rules, real registration profiles, supported integrations, access controls and versioned review records.
How I used AI
- Tools: I worked with the Pi coding agent and OpenAI models through a continuous chat, refining the analysis and prototype. The agent used Python for counts, HTML/CSS for the pages and JavaScript for the prototype’s classification logic.
- Analysis: AI grouped the issues. I challenged its ranking: 83% of tickets were closed, so volume alone was misleading.
- Prototype: AI generated sample expenses and built the classification and upload flow. I manually tested it and adjusted it for usability. This runs in a static HTML file; a real solution would likely be an integrated application connected to Light and other data sources.
- Weaknesses: AI drafts were too wordy. I had to cut them substantially and simplify the language. AI also assumed platform needs beyond the ticket evidence, which I corrected.
Friday message
Draft, subject to week-one findings.
Subject: Week one: priorities and next steps
The main gaps are audit access, manual expense-tax decisions and revenue reconciliation.
I suggest starting with audit-access improvements and a revenue-reconciliation pilot. With the tax lead, we’ll also check whether an expense-tax tool would complement Light’s planned changes.
Please confirm these priorities and a finance owner for each pilot. We’ll need approved access to sample data and relevant Light tickets.