Mexican Localization for Expenses
This module enhances Odoo's expense flow by ensuring that every expense results in a properly validated supplier invoice, thereby strengthening financial control and traceability. At the same time, it leverages the expense module as the primary channel for receiving and processing supplier invoices, enabling automatic fiscal and functional validations within this workflow. This approach reduces the risk of human error, simplifies daily operations, and provides a more reliable process for managing expenses in compliance with Mexican tax regulations.
Roles
In the expense management workflow, different actors participate with specific responsibilities and permissions to ensure proper control, validation, and accounting of submitted expenses. Below are the main roles involved and their functions within the process.
1. Employee:
- Person who incurs an expense on behalf of the company and requests reimbursement or justification for it.
- Any employee with access to the Expenses app can create expenses, with or without CFDI (depending on the internal policy).
- Can upload supporting documents (PDF, XML, images, etc.).
- Can group expenses into Expense Sheets.
- Can submit the expense sheet for approval.
2. Approver:
- Responsible for reviewing, approving, or rejecting expense sheets submitted by employees.
- In case of rejection, they must provide a reason.
It can be:
The employee's expense manager.
The employee's direct manager.
The manager of the employee's department.
Any user assigned as a manager in any department.
The direct manager of any registered employee.
A user with the Allow to approve expenses without being responsible permission, used when a user who is not the manager or responsible needs to approve expenses.
When the employee submits the expense sheet, an Expense Approval To Do activity is automatically created and assigned to the responsible approver. This ensures the approver is notified and can act promptly. Once the sheet is approved, the activity is automatically marked as done; if the sheet is reset to draft or cancelled, the activity is removed.
3. Accountant:
Responsible for completing the accounting part of the expense flow.
Validates approved expenses, meaning they are in charge of posting the generated invoices.
Records the corresponding payments.
May be dynamically assigned depending on:
The employee's designated accountant.
Based on whether the supplier is tagged with the Vendor category and on the currency of the expense:
If the supplier has the Vendor category or any child category under it, and the expense currency matches the company currency, the system uses the supplier's company-currency accountant, otherwise, it uses the supplier's foreign-currency accountant.
If the supplier is not tagged as a vendor, or no specific accountant is found, the system instead uses the company's default accountants for each currency.
Once an accountant is assigned, when the expense is approved by the manager, an Accounting Approval To Do activity is automatically created for the assigned accountant, with the note "Review and post the journal entries for this expense sheet." This helps organize pending invoices and ensures timely validation and posting. The activity is automatically marked as done when the sheet moves to done or is reset to draft.
Note: In the following sections, the available system parameters that influence the module's behavior are explained. To create or modify any of these parameters, please contact your system administrator to ensure that the configuration is applied correctly.
Key features
Employee Configuration
- Journal: Specifies the journal that will be used to make the reimbursements to employees, for expenses with type Employee (to reimburse). The credit and debit accounts are informative only on the employee record, as they are ultimately sourced from this journal.
- Petty Cash: Specifies the journal used to manage the petty cash assigned to the employee. This can represent either a company debit/credit card or physical cash. The journal is used to keep track of transactions related to this petty cash.
- Payment Mode: Default value for all expenses created for the employee. Indicates who paid the expense and how it should be accounted for. This can be changed directly in the expense if there is any expense with a different payment mode.
- Accountant: Specifies the user responsible for reviewing and posting expense reports after they have been approved by the employee's manager. (More details in the roles section).
- Expenses count and Sheets count: These fields are used to track the number of expenses and expense sheets associated with the employee. The current counts are accessible via the smart buttons.
Validation Logic
Before an expense can be reported or submitted for approval, a series of checks to ensure consistency and correctness is performed. The main types of validations include:
1. Functional and Business Rule Checks: These validations ensure the internal consistency and compliance with company policies.
- Structure and Workflow Checks: Prevents duplicate reporting, mixing expenses from different employees, or submitting lines that are not in draft state.
- Missing or Inconsistent Data: Validates that all expenses have a payment mode assigned, and that it's consistent across the report. Also checks if the required configuration is missing (e.g., reimbursement journal for the employee).
- Internal Business Rules: Confirms that the expense has passed internal business validations, such as VAT match, non-duplicate UUIDs, known vendors, valid currency, acceptable date range, and correct handling of refunds.
2. Fiscal and SAT (XML-based) Checks: These validations ensure compliance with Mexican tax regulations regarding the CFDI.
- Fiscal Validity: Checks that the attached XML (EDI) is valid, deductible, and not duplicated in other invoices or expenses.
- Payment Method Validation: Ensures that expenses to be paid by the company use the correct payment method (PPD) or, if paid by the employee, follow the correct configuration.
- Payment Way Validation: Confirms that expenses to be paid by the company use the correct payment way (99 - To be defined).
- SAT CFDI Status Check: Verifies that the attached CFDI exists in the SAT registry and is not cancelled.
- Tax Presence Check: Confirms that the taxes declared in the CFDI exist in Odoo and are enabled.
- Refund CFDI Link: Validates that the refund CFDI references an existing related CFDI in the system.
- Refund CFDI Node Check: Checks that refund CFDIs include the required CfdiRelacionados node.
- Local Taxes Account Assignment: Confirms that local taxes in the CFDI are present, properly configured, and have an account assigned in their tax setup.
Vendor Bill Creation: If the expense has a valid vendor, a draft vendor bill is created from it. If the expense corresponds to a credit note, a draft vendor refund is created instead.
Note:
- If a CFDI is attached to the expense, the document type (Vendor Bill, Vendor Credit Note) will be taken directly from the CFDI.
- If no CFDI is provided, you can manually select the Document Type in the expense form.
Accounting and Document Handling
Expense Payment Registration: Handles payment registration logic based on the selected payment mode and its corresponding journal.
Tolerance for Fiscal Document Differences: Supports configuration of an acceptable amount difference between the invoice total and the total stated in the attached fiscal document (such as an XML). This allows minor discrepancies (e.g., due to rounding or currency conversion) without blocking the posting process.
Automatic Partner Creation Control: When an XML expense document is uploaded, Odoo tries to find an existing vendor with the same VAT. If no match is found, a new partner is automatically created. This feature prevents that behavior by assigning all unmatched expenses to a predefined partner instead. The partner is specified through the l10n_edi_hr_expense.global_partner system parameter, which must contain the ID of the partner to use.
Journal Entries Reclassification: Allows accountants to adjust the account, product, or date of expenses and vendor bills when a reclassification is required. This may be due to internal policies, reporting needs, or specific accounting criteria. The tool avoids the need to cancel and recreate documents, keeping the workflow simple while ensuring records reflect the desired data.
Airlines Case: In certain cases involving airline expenses, the invoice concept (in the CFDI) includes multiple tax bases that do not apply uniformly across the total amount. For example:
Concept: Total = 4497.00
Taxes: 0% - Base = 1125.00 | 16% - Base = 3372.00
The concept has multiple tax bases, but the total is not applied to the whole amount. In this case, the line must be split (one line per tax base). To enable this feature, the supplier must have the Is Airline tag enabled.
Avoid search of products from CFDI: By default, when creating invoices from expenses with an attached CFDI, the system automatically tries to find the matching product in Odoo using the product code or description from the XML file. If you prefer to disable this automatic product search, you can set a system parameter named l10n_edi_hr_expense.restrict_product_search to True. When this parameter is enabled, the product defined on the expense will be directly assigned to the vendor bill line instead of searching for a match in Odoo.
This can help avoid errors or improve performance when the CFDI product information does not perfectly match the products in your system.
Special Fiscal Cases
Configure Fuel SAT Codes: Configure SAT codes for fuels, which are published by the SAT in its product catalog. The code range from 15101500 to 15101515 is already registered by default, so it is not necessary to add them manually. Additionally, the module properly handles fuel CFDIs where the IEPS tax is included implicitly and not as a separate invoice line. When the CFDI concept uses a fuel SAT code and has exactly one tax, the system automatically splits the line: the base amount (the taxable portion) is placed on the main invoice line, and the implicit IEPS amount is placed on a separate FUEL - IEPS line with no taxes, so that the invoice total matches the CFDI exactly.
Subsequent Taxes Configuration: Subsequent taxes are special or local taxes (such as IE and IEPS) that apply on the base of a primary tax, usually VAT.
In our expenses module, you can configure them through a system parameter called l10n_mx_edi_hr_expense.subsequent_taxes. This parameter is a dictionary where the keys are the names of the subsequent taxes (e.g., 'IE' or 'IEPS') and the values are lists of the related primary tax IDs (typically VAT).
This means the subsequent taxes IE and IEPS are linked to the primary taxes with IDs 1 and 2.
Attention: If the primary tax (for example, VAT with ID 1 or 2) is not present on the invoice, then the associated subsequent taxes (IE, IEPS) will not be added.
Omit Specific Local Taxes from Validation: In some cases, certain local taxes included in a CFDI should not be created or validated, as they must be recorded directly as part of the expense. To handle these cases, you can configure a system parameter named l10n_taxes_for_expense. This parameter must contain a comma-separated list of tax names (as they appear in the CFDI) that should be omitted from functional checks.
Journal Configuration for Employees
This module relies on a dedicated Expense Journal being configured on the employee record. This journal is essential as it defines the employee's Petty Cash account (for cash flows) and the default Reimbursement account (to track the company's liability).
The journal can be created either automatically or manually.
Automated Journal Creation
This is the recommended method for initial setup or batch configuration.
- Enable the automated action named "hr_expense: Auto create journal on all employees" (available in Settings > Technical > Automated Actions).
- This action will create and assign a new, unique Journal (named after the employee) to every existing employee record that currently lacks one.
Manual Journal Configuration
To configure the journal manually, follow these steps:
- Go to Accounting > Configuration > Journals and create a new journal, typically named after the employee (e.g., 'Employee Name' Petty Cash).
- On the employee's record (Human Resources > Employee), assign this newly created journal to the field Expense Journal.
Required Journal Fields
The following fields must be configured on the assigned Expense Journal, as they dictate the accounting behavior:
Type: Must be set to Cash or Bank, accordingly.
Cash account: The account used to record the physical cash/bank movements of the employee's petty cash.
Note: If too many journals appear on the dashboard, you can click “Remove from Favorites” to hide them. By default, newly created journals are automatically marked as favorites.
Supplier Tags for Expense Management
This module defines several partner categories to enhance the behavior of the expense and vendor bill flow. These tags allow finer control over invoice creation, validation, payment registration, and CFDI consistency.
Suppliers: Parent tag used to group all the tags relevant to expenses and vendor bills. It also serves to differentiate purchase vendors from other types of partners.
Created for Expenses: Applied automatically to vendors created from an XML uploaded through the expense module. When the system detects a new VAT in the CFDI that doesn't match any existing partner, it creates one and assigns this tag to indicate its origin (This tag is assigned automatically and should not be added manually).
Auto validate Vendor Bills: Each night, an automated process checks for expenses with this vendor tag that have not yet been included in an expense report. These expenses are automatically grouped, a report is generated, and subsequently validated by the automated process.
- Note: The scheduled action "hr_expense: Create sheet daily (Auto validate)" that drives this behavior is disabled by default. To activate it, go to Settings > Technical > Scheduled Actions and enable it manually.
Split Taxes Vendor Bills: Used for vendors (e.g., airlines or logistics companies) that issue CFDIs with a single concept line but multiple tax bases (e.g., part taxed at 0% and part at 16%). This tag triggers the system to split the line into two, so taxes are correctly applied and totals match the CFDI.
Force Invoices Total: Some suppliers round amounts differently or use more than two decimal places in their systems, causing mismatches between the CFDI total and the invoice in Odoo (it should only be used when necessary, as it affects invoice computation performance). This tag adjusts the unit price to ensure that:
Unit Price = Total / Quantity (from CFDI)
Omit amount check with EDI: Normally, when validating an invoice that includes a CFDI, the system checks that the total amount matches. This tag disables that check, useful for cases like customs agents who may charge extra fees not included in the CFDI (use this tag with caution).
Force Invoice Creation: Used for vendors that do not issue CFDIs (e.g., foreign suppliers). With this tag, a vendor bill is created based on the data provided in the expense form, instead of relying on XML parsing.
Vendor: Marks a partner as a vendor for accounting or purchase purposes. This is used to formally designate a partner as a vendor for accounting or purchase purposes. For instance, a quick-service store (e.g, Oxxo) may not require this tag even if purchases are made.
Auto Accrue Expenses: This works in conjunction with the previous tag. When present, after the expense report is automatically validated, the system will also automatically accrue the related invoices (provision vendor bills).
- Note: ** This tag only takes effect when the **"hr_expense: Create sheet daily (Auto validate)" scheduled action is enabled (see note above).
Omit autogenerate expense payments: When a vendor has this tag, vendor bills generated from expenses using the Company Account payment mode will not have payments automatically created and posted. This allows specific vendors to be excluded from the standard automatic payment flow when manual payment processing or alternative accounting treatment is required.
Usage
Expense State Flow
Each expense moves through the following states as it progresses through the workflow:
| State | Triggered by | Description |
|---|---|---|
| downloaded | Expense created or imported (XML upload, email alias) | Initial state. The expense exists but has not yet been validated. |
| draft | ACK processed successfully | Fiscal and functional validations passed. The expense is ready to be reported. |
| reported | Expense added to an expense sheet | The expense is grouped into a sheet but not yet submitted for approval. |
| submitted | Employee submits the expense sheet | The sheet is pending review by the approver. An Expense Approval activity is created for the manager. |
| approved | Manager approves the expense sheet | The sheet is approved. A draft vendor bill is generated and an Accounting Approval activity is created for the accountant. |
| post | Accountant posts the journal entries | The vendor bill is posted. Payment is pending. |
| done | Payment registered and reconciled | The expense is fully processed and closed. |
| refused | Manager rejects the expense sheet | The sheet is returned to the employee with a rejection reason. |
Create an expense and pay special attention to the field Payment By because the behavior will vary depending on whether the employee needs to be reimbursed.
Payment modes:
Employee (to reimburse): The employee pays the expense with their own money, and later the company reimburses them. (Requires the associated journal to be configured on the employee record.)
Company (Generate a payable for the supplier): The employee incurs the expense with a supplier on behalf of the company. The payment responsibility is recorded directly as a company payable rather than being reimbursed to the employee.
Petty Cash (Debit from the custody of the employee): The employee uses petty cash funds to pay for the expense, and later the petty cash is replenished by the company.
The journal used for petty cash must be configured as a Petty Cash journal. Defining a Petty Cash Reserve allows the system to suggest how much to deposit in order to maintain the petty cash account at its minimum balance.
- Note: If the company's account does not have enough funds to fully replenish the petty cash, the suggested amount can be adjusted. In that case, the petty cash will only be partially topped up, and any missing balance —for example, if overspending occurred — must be recovered later through an internal transfer.
Expense creation alternatives:
Create the expense first, then attach the XML file.
Upload the XML file directly, which will create the expense automatically. In this case, the assigned employee will be the one linked to the currently logged-in user.
You can define an email alias (for example, expenses@domain.com). Emails sent to this alias can automatically generate an expense.
Click the button "ACK" to perform all previously mentioned fiscal and functional validations on the expense.
After this, run fiscal and functional checks. You will see a summary on the expense showing which checks passed and which failed. You will also have access to a detailed view of each validation to facilitate corrections.
- Note: If the attached CFDI is a payment complement (TipoDeComprobante = P), the expense is automatically archived during ACK. Payment complement documents confirm that a previously issued invoice has been paid and should not generate a new reimbursable expense, so the system discards them at this stage.
Additionally, an email is automatically sent to the related employee with the results of the validations, ensuring they are aware of any issues that need to be addressed.
Note: By default, the email with the validation results is sent automatically. It is possible to disable it by adding the system parameter l10n_edi_hr_expense.disable_ack_send_email and setting it to True.
Create an expense report directly from the expense.
An expense sheet also could be created by grouping one or more expenses.
Note: In the expense sheet, expenses whose SAT validation status is different from valid are highlighted in yellow. This applies in cases when the CFDI state is:
- Not defined (none), i.e., cannot be managed with SAT.
- Could not be found in SAT (not_found).
- Cancelled in SAT (cancelled).
- More than one invoice to check with SAT (more_than_one).
Additionally, expenses without a CFDI are highlighted as not synced with SAT (undefined). Highlighting these expenses helps the expense approver identify cases that may require review or observation.
Submit the expense to manager
On submission, two automatic activities are triggered:
An Expense Approval activity is assigned to the responsible approver (as described in the Approver role).
If any individual expense line exceeds the amount configured in Company > Limit amount for expenses, an Expense exceeds amount limit activity is created for each employee listed in Company > Employees. This alerts the designated reviewers before or during the approval process. Unlike the other activities, this one has no automatic cleanup and must be closed manually once reviewed.
- Note - Both fields must be configured for this activity to trigger: if Limit amount for expenses
- is zero or not set, no activity will be created regardless of the expense amount.
Approve the expense (if the attached CFDI, PDF, or the expense itself is valid). This task is performed by the approver, who updates the status of the expense report sheet to allow the workflow to continue. A vendor bill is automatically generated from the expense data but remains in draft (open) state until further processing by the accountant.
Once the expense report sheet has been approved by the manager, the accountant is responsible for posting the journal entries. This is done by executing the action Post Journal Entries on the expense report sheet. At this point, the vendor bill generated from the expense is posted.
- Note: If the product in the CFDI is not found in the system when the invoice is created, it will be taken from the product assigned in the expense.
Once the expense report sheet has been approved and journal entry posted, the accountant handles the actual payment depending on the Payment By method selected for the expense:
- Employee (to reimburse): If the employee paid with their own money, the expense creates a negative balance in the employee's journal, which represents the amount the company owes to them. To reimburse, create an internal transfer from the company's journal to the employee's journal.
Petty Cash (Debit from employee custody): If the employee used petty cash funds, the petty cash journal will reflect the debit. To restore the petty cash balance, create an internal transfer from the company's journal to the petty cash journal.
Company (Generate a payable for the supplier): If the company pays the expense directly, a vendor bill is generated from the expense.
After posting the journal entries:
Register the payment for the vendor bill generated from the expense.
Confirm the payment.
Note: Internal transfers in Odoo are a native feature. For more details, see the official documentation or this video tutorial.
Considerations: Taxes defined in the CFDI are automatically searched in Odoo by their SAT Tax Type consider if the tax is IVA, IEPS, ISR or Local. If there are more than one resulting tax for a given rate, it will be taken from the one configured in the product as a vendor tax, or the first available one if there is not any configured.
Automatic ACK Processing: In addition to the manual button, a scheduled task - cron runs every 2 minutes to automatically process all newly created or imported expenses that are ready for acknowledgment (in the downloaded state). The cron executes the same validations as the ACK button and sends the acknowledgment emails automatically.
Advance Payments Handling - Merge Expenses
Sometimes, employees need to pay suppliers in advance for services (e.g., company car maintenance) before receiving the corresponding CFDI. To handle this, the module provides a workflow using the Merge Expense feature to reconcile advance payments.
Usage of merging expenses:
The employee creates a new expense for the full service amount, assigns the supplier, and marks the record To be check, then, creates an expense report and completes the flow up to Post Journal Entries.
When the CFDI is received, create a new expense for the same supplier and employee (or upload the XML directly). In the new expense, press the Merge Expense button.
A wizard will show previous expenses that can be merged. Only expenses that match the same supplier, same amount, have no CFDI attached and are marked To be check will appear. If other unrelated expenses show up, remove them from the selection.
Click the Merge Expenses button.
As a result, the original expense is archived, and the new expense replaces it, ensuring proper accounting, reporting, and workflow continuity.
Credits
Contributors
- Nhomar Hernández <nhomar@vauxoo.com> (Planner/Auditor)
- Luis Torres <luis_t@vauxoo.com> (Developer)
- Andrea García <andreag@vauxoo.com> (Developer)
Maintainer
This module is maintained by Vauxoo.
A Latin American company that provides training, coaching, development and implementation of enterprise management systems and bases its entire operation strategy in the use of Open Source Software and its main product is Odoo.
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Expenses (hr_expense)
• Accounting (accountant) • Invoicing (account) • Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 4396 |
| Technical Name |
l10n_mx_edi_hr_expense |
| License | OPL-1 |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module