When building full-stack financial apps, your standard math logic needs serious guardrails.

Today (Day 80 of my build!), I was fine-tuning the Month-End Projection widget for my AI Financial Agent.

The Problem: My React dashboard looked great, showing €86 in expenses. But my Serverless Python backend was returning a projection of €168. To make matters worse, if I clicked on "April" (a past month), the system would project a completely broken number instead of just showing the final closed amount.

The Fix: I had to implement three architectural changes to force my backend to respect the passage of time and match the frontend's business logic.

1. Aligning Business Rules (The Mirror Filter) My React code was hiding internal currency conversions (like Wise "To EUR" transfers) from the expense chart. But my Python Lambda was just summing up everything that wasn't an income. Fix: I added an aggressive regex-style filter in the backend to match the UI perfectly.

Python

Aggressive Filter for Wise and Plaid

is_internal = (
t.get('is_internal', False) or
any(x in desc for x in ['to eur', 'to usd', 'to gbp', 'balance', 'conversion'])
)
if not is_income_tx(desc, amt) and not is_internal:
target_month_expenses += abs(amt)

1. The "Smart Sync" Pattern
   I have a 7 AM Cron Job that fetches new bank data daily. But what if the month rolls over to May 1st at 2 AM, and the user logs in before the Cron runs? They would see an empty dashboard.
   Fix: A lightweight fallback. On load, the Lambda checks the server's absolute clock. If the DynamoDB query for the current month (2026-05) returns empty, it forces a real-time fetch to the bank APIs.

2. Temporal Math
   You can't calculate a "daily burn rate" projection for a month that is already over.
   Fix: The backend now checks the target month against the current system month. If it's a past month, projected_spend = total_expenses. Period.

Code for the happy path, but architect for the edge cases!