ExpenseOnDemand API integration services (OpenData / OpenFinance)

Real, auditable financial data at source

Unlike a personal budget tracker, ExpenseOnDemand sits inside finance departments of small businesses, mid-market firms and global enterprises. Every record is captured at source via the mobile app or web portal, automatically tagged with cost centre, project, currency and tax codes, then routed through approval rules. That means an integration is not just connecting an app, it is opening a stream of board-grade financial data: travel expenses, subsistence, entertainment, mileage, mileage rates, credit card charges and VAT-reclaimable line items.

Open APIs already exist — but stitching them is the work

ExpenseOnDemand publishes an Azure-hosted developer portal (developer.expenseondemand.com) plus an APIDeck-powered two-way sync layer. The endpoints are real, but mapping them into a customer's chart of accounts, departmental hierarchy, multi-entity payroll and cross-border reimbursement rules is a custom engineering effort. That is where our studio adds value: we deliver the glue, not just a wrapper.

OpenFinance angle for receipts and reimbursement

Reimbursement is a payment event. When ExpenseOnDemand approves an expense, the downstream pay-out (via payroll, virtual card or bank transfer) is exactly the kind of flow OpenFinance and OpenBanking initiatives target. Combining ExpenseOnDemand statement data with PSD2 / Open Banking account data gives finance teams a closed-loop view of who claimed what, when it was paid and how it was reconciled.

1. OAuth & session login module

Mirrors the ExpenseOnDemand mobile and web sign-in flow: subscription key acquisition, OAuth 2.0 token exchange against the Azure API Management gateway, refresh-token rotation and per-tenant subscription handling. Used to bind employer tenants, claimants, approvers and finance admins under one programmatic identity.

2. Expense statement & report API

Exposes paginated expense lists with date-range and status filters (draft, submitted, approved, reimbursed). Each row carries amount, currency, exchange rate, category, project, mileage flag, VAT amount and approver chain — directly consumable by reconciliation and reporting dashboards.

3. GPS mileage tracking ingestion

The app uses a foreground service with persistent notification to track mileage. We surface the resulting trip records (start_lat, start_lng, end_lat, end_lng, distance_km, rate, claim_amount, business_purpose) so they can be cross-checked against Google Maps triangulation and pushed into payroll for tax-aware reimbursement.

4. OCR receipt extraction service

ExpenseOnDemand's receipt scanning runs OCR with stated 99.9% claim accuracy and supports multi-page captures. Our module returns the structured receipt JSON (merchant, date, sub-totals, tax_breakdown, line_items[]) plus the original image URL, so receipts can be archived in your document management system or e-invoicing workflow.

5. Cost centre, project & employee master data

Two-way sync of cost centres, projects, claimants, approvers, grades and additional custom fields. Critical for organisations whose finance hierarchy lives in NetSuite, Microsoft Dynamics, Xero or Sage and needs to stay consistent with the expense app.

6. Approval workflow webhooks

Subscription to status-change events: "submitted", "approved by manager", "rejected", "reimbursed". Used to trigger downstream payments, notify Slack/Teams channels or update an audit ledger in real time.

Scenario A — ExpenseOnDemand → QuickBooks / Xero nightly close

Context: A UK-based services firm closes books weekly; finance staff currently re-key approved expense reports from ExpenseOnDemand into Xero.

Data & APIs: /expenses?status=approved&from=...&to=... → Xero Bills/Invoices API. Fields mapped: expense_id → reference, employee_id → contact, category → account_code, vat_amount → tax_amount, currency → currency_code.

OpenData mapping: Each approved claim is treated as a structured "transaction object" published by an OpenFinance source, then ingested by the accounting platform via the standard accounting OpenAPI bindings.

Scenario B — Mileage feed into payroll for tax-compliant reimbursement

Context: A field-services company pays drivers by HMRC AMAP rates. They need a defensible mileage record per pay period.

Data & APIs: /mileage?employee_id=...&period=YYYY-MM → payroll service. We fetch trips with start_lat/start_lng/end_lat/end_lng/distance_km, apply rate bands, deduplicate against credit-card fuel charges and post net-of-tax amounts to payroll.

OpenData mapping: Mileage trips become a dedicated open dataset feeding both reimbursement and ESG reporting (CO₂ emissions per km).

Scenario C — Receipt OCR data into e-invoicing & VAT reclaim

Context: A multi-entity EU group must store digitised receipts and reclaim VAT under local rules.

Data & APIs: /receipts?id=... returns merchant, vat_breakdown[], line_items[], image_url. We extract reclaimable VAT, match to expense IDs and forward to the group's e-invoicing platform (e.g. PEPPOL connector).

OpenData mapping: Treat each receipt as a structured invoice fragment; the integration becomes an OpenData publisher of "deductible-VAT events".

Scenario D — Real-time approval webhook → corporate card pay-out

Context: A scale-up wants to fund employee virtual cards within minutes of an approval, instead of monthly batch reimbursement.

Data & APIs: Webhook on status="approved" → corporate-card issuer top-up API. Carries claim_amount, currency, employee_id, claim_id.

OpenFinance mapping: Combines an OpenData expense event with an OpenBanking initiated payment under PSD2, closing the loop end-to-end.

Scenario E — Cross-border consolidated reporting for a group HQ

Context: A holding company needs monthly consolidated travel-and-entertainment reports across UK, EU, India and US subsidiaries.

Data & APIs: Tenant-scoped /expenses pulls per subsidiary, FX-normalised to GBP, joined with cost-centre master data and pushed to a BI warehouse (Snowflake / BigQuery).

OpenData mapping: Each subsidiary tenant exposes the same canonical schema; the consolidated layer is itself a downstream OpenData product the CFO office can query.

Deliverables checklist

• API specification (OpenAPI 3.1 / Swagger) covering login, expenses, mileage, receipts, master data, webhooks
• Protocol & auth report (subscription keys, OAuth flow, refresh rotation, request signing)
• Runnable source for the ExpenseOnDemand connector in Python or Node.js
• Unit + integration test suite, plus sandbox credentials guidance
• Compliance pack (GDPR data-flow map, retention policy, consent and audit logging)

API example: OAuth login (pseudocode)

// Step 1 — exchange subscription key + user creds for a token
POST /oauth/token
Host: developer.expenseondemand.com
Ocp-Apim-Subscription-Key: <SUB_KEY>
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=finance@acme.com
&password=***&tenant=acme&scope=expenses.read mileage.read

Response:
{
  "access_token": "eyJhbGciOi...",
  "expires_in": 3600,
  "refresh_token": "rt_...",
  "tenant_id": "acme"
}

API example: expense statement export

POST /api/v1/eod/expenses.export
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "tenant_id": "acme",
  "from_date": "2026-03-01",
  "to_date":   "2026-03-31",
  "status":    ["approved", "reimbursed"],
  "currency":  "GBP",
  "include":   ["receipts", "vat", "cost_centre"]
}

200 OK
{
  "expenses": [
    {
      "expense_id": "EXP-10293",
      "employee_id": "EMP-42",
      "category":   "Travel - Mileage",
      "amount":     128.40,
      "currency":   "GBP",
      "vat_amount": 21.40,
      "cost_centre":"CC-LON-OPS",
      "project":    "PRJ-CRM",
      "approval":   { "state": "approved", "approver_id": "EMP-7" },
      "receipts":   [{ "id": "R-7712", "url": "https://.../R-7712.jpg" }]
    }
  ],
  "next_cursor": "eyJwYWdlIjoyfQ=="
}

API example: mileage webhook

POST /webhooks/eod/mileage   (your endpoint)
Content-Type: application/json
X-EOD-Signature: t=1714291200,v1=...

{
  "event": "mileage.completed",
  "trip_id": "MIL-558",
  "employee_id": "EMP-42",
  "started_at": "2026-04-22T08:14:00Z",
  "ended_at":   "2026-04-22T09:02:00Z",
  "distance_km": 41.7,
  "rate_per_km": 0.45,
  "claim_amount": 18.77,
  "currency": "GBP",
  "purpose": "Client visit - Acme Ltd",
  "geo": {
    "start": { "lat": 51.5074, "lng": -0.1278 },
    "end":   { "lat": 51.4545, "lng": -2.5879 }
  }
}

// Verify HMAC, idempotency on trip_id, then forward to payroll.

Regulations we design against

• GDPR (EU/UK): data-minimisation on exports, lawful-basis records, subject-access response paths and 30-day breach-notification readiness.
• UK HMRC mileage rules (AMAP): proper rate bands, audit trail per trip, retention long enough to satisfy HMRC review windows.
• VAT / GST rules: accurate split of VAT-reclaimable amounts on cross-border travel, support for EU VAT rates and Indian GST.
• SOC 2 / ISO 27001 alignment: encryption in transit and at rest, scoped subscription keys per tenant, role-based access on the integration layer.
• PSD2 / OpenBanking: if the integration triggers payments to employee accounts, we use authorised PISP/AISP partners rather than scraping.

Data flow / architecture

A typical pipeline looks like this — kept deliberately simple so it can be audited:

1. Client App / Tenant — ExpenseOnDemand mobile and web users submit expenses, mileage and receipts.
2. Ingestion / API layer — our connector calls the ExpenseOnDemand Open API (Azure APIM) with OAuth 2.0 and subscription keys, applying retry and back-off.
3. Storage & transformation — normalised tables in your warehouse (Snowflake, BigQuery, Postgres) with field-level encryption on PII.
4. Output / API — outbound feeds to QuickBooks, Xero, Sage, NetSuite, payroll or a custom OpenData endpoint your downstream services can query.

Who we are

We are an independent technical studio specialising in App interface integration and authorised API integration. Our engineers come from fintech, payments, accounting platforms and protocol-analysis backgrounds. We have shipped expense, payroll, banking and ERP integrations for clients in the UK, EU, India, the Middle East and North America, and we know how to navigate the difference between a published Open API and a real production integration.

• Protocol analysis, OpenAPI design, SDK packaging and security review
• Native connectors for QuickBooks, Xero, Sage, NetSuite, Microsoft Dynamics
• Custom Python / Node.js / Go SDKs and test harnesses
• Source code delivery from $300 — runnable code and full documentation; pay after delivery upon satisfaction
• Pay-per-call API billing — call our hosted endpoints and pay only per request, with no upfront fee

Contact

Send us your target app and integration requirements, and we will reply with a scoped quote and timeline. Authorised use cases only.

Open contact page

Engagement workflow

1. Scope confirmation: integration scenarios, data types, target systems (1 business day).
2. Protocol analysis & API design — endpoints, auth, schema (2–5 business days).
3. Build & internal validation against ExpenseOnDemand sandbox (3–8 business days).
4. Documentation, sample data, test cases (1–2 business days).
5. Typical first delivery: 5–15 business days; third-party reviews may extend timelines.

FAQ

What do you need from me?

How long does delivery take?

How do you handle compliance?