The Problem

Modern finance teams struggle with fragmented systems, manual reconciliation workflows, and limited visibility into cash flow and vendor relationships. Rever attempts to address this with an AI-enabled finance automation platform, but the codebase shows significant structural and quality debt that would impede reliable deployment or extension.

What This Does

Rever is a full-stack finance automation platform with a Django REST backend (api/) and a React/Next.js frontend (web/ and packages/). The core finance logic lives in api/rever/app/serializers/payable.py (22 functions, 30 classes, handles vendor validation, create/update, getreject_reason) and api/rever/db/models/payable.py (22 functions, 24 classes, defines get_next_number, generate_bill_number, approve_bill). The intellidocs subsystem (api/rever/intellidocs/) handles OCR and document parsing via api/rever/intellidocs/parsers/base.py (13 functions, makes outbound network calls through boto3/minio). A committed .env file at api/.env.example.local contains live credentials that must be rotated. The internal call graph has 321 edges; create is called from 16 places, process_document_ocr_task from 11, and get_organization from 8. The most connected module is packages/common/src/index (99 exports, 0 imports - unstable, instability 1). A hub module at packages/services/src/api/axios.ts is depended on by 12 other modules, creating a blast-radius risk for any change there. No test files exist in the repository.

How It Is Wired

Execution enters through handle at api/rever/db/management/commands/setup_storage.py:14 (reaches 10 functions, called by nothing else in the repo) or setUp at api/rever/intellidocs/tests.py:31 (reaches 7 functions, called by nothing else). The call graph traces: handle -> check_minio_connection [network via boto3.client] and setUp -> create [db via Address.objects.create]. api/rever/app/serializers/payable.py is the most central file - 22 functions, 30 classes, called from 4 other files, reads/writes the database. It defines _get_reject_reason, create, update, validate_vendor, validate_purchase_order. Downstream, api/rever/db/models/payable.py (22 functions, 24 classes) implements get_next_number, generate_bill_number, update_duplicate_flags, revoke_receipt_if_needed, approve_bill. api/rever/app/views/payable/base.py (47 functions, 10 classes) implements get_queryset, get_serializer_class, perform_create, create, update. api/rever/app/views/auth/base.py (23 functions, 18 classes) defines repetitive post handlers. api/rever/intellidocs/services/ocr_service.py opens files without a context manager, risking resource leaks. The packages directory contains 171 files with packages/common/src/index as the most connected module (Ca 0, Ce 99).

How To Use It

Setup: This repository uses Django on the backend and Next.js/React on the frontend. Dependencies are managed with pnpm (root package.json and packages/common/package.json) and pip/uv (api pyproject.toml and requirements.txt). Docker is configured via docker-compose.yaml, docker-compose-local.yaml, and api/Dockerfile.api. No explicit build or run scripts are documented beyond the compose files.

Configuration: Environment variables are defined in api/.env.example and api/.env.example.local. The latter contains committed credentials that must be git-removed and rotated. Additional examples exist at api/.env.selfhosted.example and web/.env.development.

Running it: Start the stack with docker-compose up -d (or docker-compose -f docker-compose-local.yaml up -d for local development). The Django dev server runs via api/manage.py. No standalone CLI entry point is documented outside the management command setup_storage.

Real-World Use

A CFO or finance operator uploads a bill PDF or purchase order through the React frontend (packages/common/src/pages/bill/). The file flows into api/rever/intellidocs/parsers/base.py which invokes OCR via api/rever/intellidocs/services/ocr_service.py (network call to Minio/boto3). Extracted data is validated through api/rever/app/serializers/payable.py (validate_vendor, validate_purchase_order), then persisted to PostgreSQL via api/rever/db/models/payable.py. An approval workflow routes the bill through api/rever/app/views/payable/base.py and api/rever/app/views/approval/base.py, with audit trails logged automatically. Two-way matching compares bill items against PO items using api/rever/services/matching/rules.py and api/rever/services/matching/drag_drop.py.

Code Health & Issues

The static analysis produced 62 measured findings across 7 kinds, plus 11 code health audit findings:

  • HIGH - No test suite: 314 source files with zero test files. Any change ships with no regression signal.
  • HIGH - Committed .env: api/.env.example.local and web/.env.development contain live credentials; risk of secret exposure in any public clone.
  • HIGH - Third-party GitHub Actions unpinned: jlumbroso/free-disk-space@main, docker/setup-buildx-action@v2, docker/setup-qemu-action@v2, docker/login-action@v2 use mutable tags.
  • MEDIUM - Broad exception handling: api/rever/db/models/payable.py, api/rever/app/views/auth/base.py, api/rever/app/views/payable/base.py catch Exception broadly.
  • MEDIUM - Hub module risk: packages/services/src/api/axios.ts depended on by 12 modules; high churn risk.
  • MEDIUM - File leak: api/rever/intellidocs/services/ocr_service.py opens files without with statement.
  • MEDIUM - Dependabot/renovate absent: 11 manifests with no update bot configured.
  • MEDIUM - GITHUB_TOKEN permissions not restricted: 2 workflows declare no permissions, 1 references secrets.
  • MEDIUM - Container base image not pinned: api/Dockerfile.api uses python:3.12-slim without digest.
  • MEDIUM - Install lifecycle script: package.json has a preinstall script that runs during npm install in CI.
  • LOW - No job timeouts on 3 workflows.

The Bottom Line

This is a feature-rich finance automation platform with a solid Django/React foundation and genuine OCR/document-processing capability. However, the codebase carries substantial technical debt: no test coverage, committed secrets, unpinned CI dependencies, and oversized, duplicated files that make safe modification difficult. It is usable for evaluation or internal deployment with the immediate fixes (rotate credentials, pin action SHAs, add basic tests), but would require a dedicated refactor cycle to bring into a production-grade state. Teams needing rapid prototyping of finance workflows can get value quickly; organizations requiring long-term maintainability should budget for significant cleanup.