Back to selected work
ML SaaS · Financial operations Deployed

Payrithm

An accounts-receivable intelligence platform that predicts late payments, estimates payment timing, forecasts cash receipts, and prioritizes collection work.

Open application Source code Read technical article
  • Python
  • FastAPI
  • scikit-learn
  • React
  • TypeScript
  • PostgreSQL
  • Celery
  • Redis
  • Docker
Payrithm — application preview
Prediction tasks
Classification + regression
Validation
Chronological holdout
Architecture
Multi-service SaaS

System design

Payrithm architecture

React frontendDashboards, imports, configuration and collection workflows
FastAPI applicationAuthentication, validation, business rules and prediction APIs
PostgreSQLTenants, invoices, customers, predictions and model records
Celery workersCSV imports, model training and scheduled processing
RedisJob queue and worker coordination
ML pipelineFeature generation, validation, training and monitoring

The problem

Accounts-receivable teams may need to manage hundreds or thousands of open invoices without knowing which ones are most likely to be paid late.

Treating every invoice equally wastes collection capacity. Payrithm is designed to identify risk early and convert that risk into a clear operational queue.

My approach

Payrithm uses two related machine-learning models:

  • A classifier estimates the probability that an invoice will be paid late.
  • A regressor estimates payment delay relative to the due date.

The system separates issue-time model features from live operational signals. This prevents current overdue status, future reminders, and final payment information from leaking into model training.

Data preparation

The import pipeline validates identifiers, invoice amounts, currencies, issue dates, due dates, and payment dates before records become training examples.

Customer-history features are reconstructed as of each invoice’s issue date. Only outcomes known before that date are included.

Validation

The latest portion of resolved invoices forms the evaluation period. Earlier invoices form the training period.

This chronological split reproduces the real deployment direction: train on the past and predict future invoices.

The classifier is evaluated using:

  • ROC-AUC for ranking quality
  • Brier score for probability quality
  • Calibration analysis
  • A constant-probability baseline

The regression model is evaluated using mean absolute error and a median-delay baseline.

Turning predictions into decisions

The final collection score combines:

  • Late-payment probability
  • Invoice amount percentile within its currency
  • Due-date urgency
  • Reminder pressure

Keeping this formula separate from the model makes business policy adjustable and allows users to understand why an invoice appears near the top of the queue.

Architecture

The application separates the frontend, API, application services, background workers, persistence layer, and machine-learning pipeline.

This makes imports and model training asynchronous while keeping the API responsive.

Current status

The main application modules are implemented. The next steps are to complete production evaluation, publish final model metrics, expand monitoring, and collect feedback from potential users.