Brazilian CLT payroll in Odoo —
production-validated, now open source.

No. KMEE built the CLT payroll module for ABGF (Agência Brasileira Gestora de Fundos), a KMEE client — the system ran in production on Odoo 8.0 for years issuing monthly paychecks. The current PR brings that same KMEE-authored code migrated to Odoo 16 and donated to OCA. The 'Beta' badge in the manifest reflects the migration + OCA review cycle, not method immaturity.

8 events: S-1000 (employer), S-1010 (pay items), S-1020 (tax allocation), S-1200 (monthly compensation), S-2200 (hire), S-2206 (contract change), S-2230 (leave), S-2299 (termination). The rest (S-1005, S-1070, S-1210, S-1299, S-2205, SST, S-3000, totalizers) are in migration — the legacy ABGF code exists, it's a port effort to 16.0.

Not directly in this stack. Reinf lives in a parallel, complementary OCA stack (`l10n_br_reinf`). For companies that need R-2010, R-2030, R-2040 (Reinf for legal entities), we work the integration separately.

Not automated today. It depends on period closing (S-1299) + totalizers (S-5001/5002/5003/5011) + Reinf integration. Those components are in the migration queue.

Yes. The code is in github.com/kmee/kmee-odoo-addons (incubator) and on its way to github.com/OCA/l10n-brazil (final destination). You can run it, modify it, contribute. No per-employee fee, no MDR on payroll.

ABGF (federal public agency) has used it in production on Odoo 8.0 for years. New clients are starting to adopt as the 16.0 version stabilizes. If your company needs an event still in migration, KMEE can prioritize the port with paid scope.

The modernized version in the current PR is Odoo 16 + OCA l10n-brazil 16.0. ABGF runs Odoo 8.0 in production. OCA versions 17 and 18 don't yet have the full Brazilian account/sale/purchase stack, so payroll on 17/18 comes later.

ICP-Brasil A1 (PFX), reusing OCA's `l10n_br_fiscal_certificate` module. The same A1 certificate that signs NF-e/CT-e/MDF-e signs eSocial events. Optional external vault (HashiCorp, AWS, Azure, GCP).

Direct to the federal eSocial environment (homologation `tp_amb=2` or production `tp_amb=1`). The `esociallib` library handles parsing, XSD validation and SOAP. Batch ≤ 50 events (government rule), automatic classification by group (1=tables, 2=non-periodic, 3=periodic).

The `l10n_br.esocial.ocorrencia` model logs errors per event. A state machine allows resending: `draft → validated → pending → sent → success | error | rectified`. If the government returns an error, the event goes back for correction without blocking the entire batch.

Not native today. On the roadmap. If your company needs a portal/digital paystub with QR Code, we can scope custom development.

Only Odoo core `hr.attendance`. Integrations with physical time clocks or apps are on the roadmap.

Years of real use at ABGF + 232 automated tests + BDD specs in `.feature` files + OCA community review when the PR merges. It's calculation logic that paid real paychecks for years.

No per-employee license. You pay for implementation (scope defined after an adoption diagnosis) and ongoing monthly support. If an event still in migration is critical to your operation, we can prioritize the port with paid scope — that work benefits the whole OCA community.

Yes. Sponsorship is a common path in OCA projects. Does your company need S-1299 closing the period tomorrow? We can prioritize with you. The code goes back to OCA — the entire Brazilian ecosystem wins.