Smart CFDI Billing System
The problem
Manual billing and income registration consumed hours of administrative work, with a high margin of human error in data entry.
The solution
Electronic billing and automated stamping platform, integrating OCR for data extraction and predictive models to project income flows.
Architecture
Node.js services for the CFDI flow (issuance, stamping, XML). Python for OCR on inbound receipts and for the income-projection model. APIs to the PAC and to the accounting store. OCR does not guess the folio: it extracts fields and a human confirms doubtful ones before stamping.
How it was measured
Figures reported by the system engineer at Idea15, Aug–Sep 2025. The 80% is the share of the capture/stamping flow that stopped being typed by hand. The 92% is projection accuracy against the firm's internal history, not a public benchmark. No third-party audit.
How do you extract a CFDI or a receipt without typing the XML by hand?
A Python service runs OCR on the inbound document, proposes fields, and a human confirms the doubtful ones. Node.js builds the XML, calls the PAC for stamping, and stores the result in the accounting store.
The work
Idea15 needed to stop typing invoices. In Mexico that is not “a nicer form.” It is CFDI, XML, complements, a PAC, and a capture error the SAT will not forgive. The work ran August–September 2025. I designed and built the issuance and stamping flow, OCR extraction, and a model that projects income from already-stamped history. Six weeks. Not a quarter of discovery.
The architecture splits the problem. Node.js owns the procedure: build the voucher, talk to the PAC, persist the XML. Python owns vision and projection: read inbound paper or PDF, propose fields, and estimate cash. APIs between them are explicit. OCR does not stamp alone. If field confidence is low, a human confirms. That is slower than a “100% automatic” demo and more honest than sending a made-up folio to the PAC. The confirmation queue is part of the product, not a later phase.
The 80% I report is the share of the capture and stamping flow that stopped being typed. The rest is still judgment: exceptions, odd complements, cases that did not deserve a model. The 92% is projection accuracy against Idea15's internal history, not a public dataset and not the SAT. Nobody outside audited those two figures. They lived through six weeks of engineering and an operator who measured them. A recruiter who asks for the 92% notebook will not find it on GitHub: the history belongs to the firm.
This is the most Mexico-specific system in the portfolio. It is not a RAG tutorial. It is stamping, OCR, and a cash model. If I later publish an article or a CFDI XML parsing utility, this is the work it comes from. Until then, this page is the source. This site's privacy notice does not cover Idea15's fiscal data; it covers Franco's contact form.
Screenshots
