Co-leading architecture and technical delivery for Axrail’s AI-native accounts payable and receivable platform.
KIP.ai by Axrail. Explore the product through its public website.
SourceFinance teams spend valuable time moving documents between inboxes, spreadsheets and accounting systems. KIP.ai brings invoice processing, reconciliation and financial workflows into a connected product.
A multi-tenant financial operations product spanning accounts payable, accounts receivable and the documents that connect them. My work combines architecture, hands-on technical delivery and the day-to-day decisions needed to keep a large product moving.
Upload financial documents, extract structured fields, inspect the source evidence, correct values and move records through review and approval. The workflow keeps people involved where financial information needs judgement.
Compare POS reports, payment-provider reports and bank statements. Review matched transactions, variances and unmatched records, then work through exceptions with their source context intact.
Turn purchase-order documents into reviewable sales-order data. Match invoices, purchase orders and goods receipts, with configurable comparisons and approval workflows for the resulting transaction groups.
Connect supported accounting systems, map fields and synchronise records. Importing data and writing changes back are separate operations, each subject to the relevant permissions.
Combine tenant isolation, role-based permissions and subscription entitlements. Give finance users the tools relevant to their responsibilities while retaining an audit trail of operational activity.
Documents and records enter through uploads or supported integrations.
Background workers turn text, images and tables into structured data.
Users inspect evidence and resolve uncertain or invalid values.
Configured rules compare records and surface exceptions.
Approved results support exports and authorised accounting workflows.
A simplified product workflow, rather than a deployment diagram.
Customer-facing finance application, typed interfaces and reusable workflow components.
Server-state fetching, navigation and asynchronous processing status in the web application.
Finance APIs, document-processing handlers and background workers.
Infrastructure defined in code, with separate application and deployment responsibilities.
Authenticated APIs and event-driven processing without managing application servers.
Web delivery, original documents, processing artifacts and exports.
Durable domain records alongside searchable projections for discovery and listings.
Queued processing, scheduled work and recovery tasks.
Model-assisted extraction and OCR, selected according to document-processing needs.
User authentication feeding server-side access checks.
This is a high-level view of the product architecture. Feature availability varies by release and configuration; it is not a claim that every capability is enabled for every customer.
Models help interpret unstructured inputs. Explicit rules, review states and authorised actions govern what happens to the resulting financial records.
Document extraction and reconciliation run through queues and workers. The application retrieves progress and results rather than holding a long request open.
Original documents remain available alongside extracted values and reconciliation results. Ambiguous dates require confirmation instead of silently becoming an assumed accounting date.
Navigation reflects permissions, but server-side checks enforce tenant ownership, user actions and product entitlements. Search projections support the experience; durable records remain the source of truth.
team pull requests reviewed & refined / day
2027 product targets: 1,000 paying companies and US$4–7.5 million ARR. These are forward-looking goals, not achieved customer or revenue figures.
For AI engineering roles, collaborations
or a conversation about further study.