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

Yes. KMEE built the CLT payroll module for ABGF (Agência Brasileira Gestora de Fundos), a KMEE client - the system has run in production on Odoo 8.0 for years issuing monthly paychecks. That same KMEE-authored code is the module donated to OCA, migrated to Odoo 16.

Tables (S-1000, S-1005, S-1010, S-1020, S-1070), worker events (S-2200, S-2205, S-2206, S-2210, S-2220, S-2230, S-2240, S-2298, S-2299, S-2300), periodic events (S-1200, S-1210, S-1299) and structural/totalizer events (S-3000, S-5001/5002/5003/5011), with ongoing evolution at OCA. Coverage for your scenario is presented in the assessment.

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.

DCTFWeb coverage depends on period closing (S-1299), the totalizers (S-5001/5002/5003/5011) and Reinf integration; the scope for your scenario is presented in the assessment.

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 has a specific priority, KMEE can prioritize it 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.

Via the Odoo portal, scoped per project. If your company needs a portal/digital paystub with QR Code, we discuss the scope in the assessment.

Only Odoo core `hr.attendance`. Integrations with physical time clocks or apps are scoped per project.

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 assessment) and ongoing monthly support. If an event has a specific priority for your operation, we can prioritize it with paid scope - that work benefits the whole OCA community.

Yes. Sponsorship is a common path in OCA projects. If your company has a specific priority, we discuss scope, timeline and the contribution that goes back to the community. The code goes back to OCA - the entire Brazilian ecosystem wins.