Projects

Every month, booking a firm's CFDIs means opening XML after XML, deciding the expense account for each one, building the journal entry, and keying the DIOT separately. It is slow, and a mistake goes unnoticed until the entry does not balance.

It reads the XML folder (loose or zipped) and pulls everything from the CFDI 4.0: issuer, recipient, 16/8% VAT, excise tax, withholdings, UUID, PUE/PPD payment method, payment complements, and related documents. It checks each UUID's status against the SAT (valid or cancelled) and generates journal entries ready to import into CONTPAQi 18.5.2, plus the DIOT TXT in the SAT's batch format.

The expense account is predicted by a machine-learning model trained per company. Every time you correct an account in the review spreadsheet, the model learns and classifies better the next month. Before writing any file it checks that debits = credits on every entry and reports the accounts it could not assign.

Teaching with real cases needs real data. But a CFDI carries clients' tax IDs, names, and company names that cannot be shown in a course, a screenshot, or a sample file.

It turns real CFDIs into anonymized copies: it swaps tax IDs, names, and company names for consistent fake data —the same vendor always gets the same alias— and keeps amounts, taxes, line items, and dates so the exercises still reconcile. The mapping is stored in SQLite, so the process is reversible.

The anonymized files are not valid with the SAT (the digital seal no longer matches); they are for demos, courses, and testing, not for stamping.

A client sends a folder with hundreds of mixed XMLs: invoices, payroll, payment complements, versions 3.3 and 4.0 all jumbled together. Before you can review anything, they have to be sorted —and once sorted, there's still the manual work of building the fiscal workpaper on top.

It auto-detects each document's version and type (CFDI 3.3 and 4.0, Payroll 1.2, Payments 2.0) and exports everything to an Excel workbook with one sheet per document type, loose or zipped XML. A viewer with a per-tab filter lets you review before exporting, and a filtered export mirrors exactly what's on screen —filtered stays filtered, complete stays complete, never the other way around. It also exports to CSV with SAT catalog values normalized (code and description, never just one), built to feed an AI without it having to guess the catalog.

It builds a cash-basis VAT workpaper inside the same Excel file: it recognizes each PUE-method CFDI in its issue month and each PPD-method one in whichever month its payment complement actually pays it —a PPD invoice with no matching payment complement in the batch is flagged "provisioned," not yet deductible or creditable— with the legal basis (specific VAT law articles) cited on its own sheet.

This is the tool I run daily in my own practice, not a demo. It's still actively growing: a multi-period historical vault and direct SAT status validation (valid/cancelled) haven't been built yet.

Workpapers get rebuilt every year, and when the format lives only in the head of whoever built it, no one else can maintain it.

An Excel workpaper system generated from code: formulas, queries, and macros versioned separately, and the final workbook is assembled by a build script instead of being hand-edited every year.

Every four months, filing the SISUB and ICSOE means cross-referencing two Excel layouts by hand, writing formulas between files for fixed earnings, editing the previous period's CSV by changing the quarter and year, and keying each contract into a 6-step web wizard —bulk upload only unlocks above 20 workers per contract, and most have 2 to 4.

Builds a single master table (worker × contract × date range) from payroll XML and Mexico's SUA contribution files, with a defined source hierarchy for each field —for example, the integrated daily wage comes from the payroll XML first and only falls back to SUA or a calculation when that's missing. From that one table it projects the 3 SISUB CSVs, the ICSOE CSV/Excel, and the firm's control workbook, replacing the VBA macros it used to run on. Before generating anything it runs a validation rule catalog that points to the exact contract, worker ID, and row behind each error.

The ICSOE web-wizard automation (via Playwright) never signs on its own: by default it leaves the filing captured and sitting on the government portal's signature screen, validated and ready, but the actual "Sign" click is always a person's. The only two irreversible steps in the whole flow are gated behind an explicit permission in the code, not good intentions.

Every month, pulling compliance documents for an entire client roster means logging into each portal one RFC at a time, solving CAPTCHAs by hand, and saving every PDF manually.

Designed to log into the SAT, IMSS, and INFONAVIT portals once a month for a whole roster of RFCs and download the SAT's tax-status certificate and compliance opinion, plus the IMSS/INFONAVIT equivalents for clients with employees, with a run log that pauses and asks for human help only when it truly cannot continue.

A small core that knows nothing about any specific portal (credentials, secrets, CAPTCHA, human pause, logging) plus one small adapter per portal that does. Two of the three domains sit behind a commercial bot manager (Imperva/Incapsula, Akamai), so the browser always runs visibly, with a persistent profile and human-like pacing, and login is never retried in a loop. The SAT CAPTCHA solver —previously a Chrome extension running a local ONNX model— was ported to Python to reuse the same core here.

Actively in progress: right now only the e.firma login against the real IMSS portal (ICSOE) is done. Actually downloading the certificates —the end goal— is the next phase, not built yet.