WarungFlow

WarungFlow is an autonomous finance agent for Indonesian UMKM. It turns messy WhatsApp orders and QRIS payments into clear cashflow reports without manual bookkeeping.

Comment

Inspiration

Indonesian warung and UMKM owners take orders on WhatsApp, accept QRIS, bank transfers, and cash, then close the day with manual notes. With tens of millions of UMKM in Indonesia and QRIS volume growing rapidly (Bank Indonesia, 2025), daily reconciliation is becoming harder, not easier. Many sellers cannot quickly answer: who has paid, who still owes, or what net profit was today. Informal bookkeeping also limits access to financing. We built WarungFlow to automate this back-office work with an autonomous agent, not another customer chatbot.

What it does

WarungFlow is an autonomous finance operations agent for Indonesian UMKM.

Given messy WhatsApp orders, a product catalogue, expenses, and QRIS-style payment logs, it:

  1. Parses and structures informal chat orders (deterministic parsing + catalogue pricing)
  2. Reconciles payments using fuzzy Indonesian name matching and order-ID priority in bank notes
  3. Flags UNPAID, PARTIALLY_PAID, OVERPAID, and NEEDS_REVIEW with clear Sisa Rp / Lebih Rp in the UI
  4. Creates payment requests in Mock mode (no API keys) or DOKU Sandbox (hosted checkout + Check Status API sync)
  5. Calculates cashflow, net profit, and a 0–100 health score
  6. Generates Bahasa Indonesia payment reminders and financing-readiness summaries
  7. Validates and exports markdown/CSV reports

The Simulasi page lets judges test WhatsApp order intake, QRIS payments, and both payment modes with reactive auto-refresh (e.g. Kevin UNPAID → PAID).

How we built it

WarungFlow is not a chatbot wrapper. It uses a state-driven orchestrator:

  • decide_next_action() plans the next step from AgentState gaps
  • run_agent_stream() runs up to 24 tool steps per analysis
  • 20 registered tools in TOOL_REGISTRY (load, parse, reconcile, cashflow, validate, export)
  • Full execution_trace with run_id visible on Jejak agen for judges

Stack: Python, Streamlit, pandas, rapidfuzz, Altair, FastAPI (optional bot server), python-dotenv.

Payment (Best Payment Use Case):

  • Mock: ?mock_pay=ORD-BOT-xxx deep links
  • DOKU Sandbox: Checkout API + HMAC signatures + Check Status poll via ?doku_pay= simulator

WhatsApp bot is an input channel only (SYNC_BOT_EVENTS). The core value is autonomous reconciliation and reporting.

AI tools used in development: Cursor IDE agent; optional Groq/Gemini for reminder tone when LLM_MODE=live. Money matching and arithmetic stay deterministic.

Challenges we faced

  1. DOKU sync without a public webhook on Streamlit-only deploy → solved with Check Status API polling on simulator return
  2. Wrong payment matches when bank notes mention multiple names → order-ID priority in reconciliation logic
  3. Indonesian name variants (honorifics, bank display names vs WhatsApp names) → rapidfuzz + normalization rules
  4. Session persistence without resetting payment mode on every page refresh

What we learned

Deterministic tools should own money matching and arithmetic. The agent loop should own planning, sequencing, and validation. Paying on a hosted checkout page alone does not update back-office books; payment gateways need explicit status sync into the agent workflow.

What's next

  • WhatsApp Business API for live order ingestion
  • Production DOKU HTTP notifications
  • POS integration and bank-ready financing export packets

Built With

  • altair
  • api
  • doku
  • event
  • fastapi
  • jsonl
  • mock
  • pandas
  • provider
  • python
  • python-dotenv
  • rapidfuzz
  • sandbox
  • store
  • streamlit
  • uvicorn
  • whatsapp
Share this project:

Updates