| 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 | 4342 |
| Technical Name |
l10n_mx_edi_hr_expense |
| License | OPL-1 |
| Versions | 17.0 18.0 |
Mexican Localization for Expenses
This module enhances Odoo’s expense flow by ensuring that every expense results in a properly validated supplier invoice, strengthening financial control and traceability. At the same time, it leverages the expense module as the main channel to receive and process supplier invoices, allowing fiscal and functional validations to happen automatically 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.
Is allowed to submit the 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. This is for cases when it is necessary that a user who is not the manager of a department or responsible for the expenses of an employee, approves expenses.
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 in whether the supplier is tagged as a vendor and the currency used:
If the supplier has an accountant for the company currency or for foreign currencies, they are preferred.
Otherwise, the company's default accountants for each currency are used.
Key features
In the employee adds fields to configure and use:
- 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 taken from this journal, and are only informative in the employee.
- 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 treated in accounting.
- Accountant: Specifies the user responsible for reviewing and approving the expense reports after they have been submitted and approved by the manager (specified in roles section).
- Expenses count and Sheets count: These fields are used to track the number of expenses and expense sheets associated with the employee. Accessible by the smart buttons.
Before an expense can be reported or submitted for approval, a series of checks to ensure consistency and correctness are performed, the main types of validations include:
- 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 required configuration is missing (e.g., reimbursement journal for the employee).
- Functional 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.
- Fiscal Validity (XML-based): 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 refund CFDIs reference 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 credit note is created instead.
Note:
- If a CFDI is attached to the expense, the document type will be taken directly from the CFDI.
- If no CFDI is provided, you can manually select the Document Type in the expense form.
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 tax ID. 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.
Supplier tags: A set of supplier categories are introduced to provide additional rules that modify how invoices are created, validated, accrued, or paid when they originate from expenses. They are especially useful for handling special fiscal cases (e.g., CFDI consistency, tax splitting, rounding mismatches) and for automating repetitive accounting tasks (e.g., auto-validation or payment of vendor bills). Each tag has a specific purpose and should only be applied when the corresponding business case requires it. Detailed explanations for each tag are provided in a later section of this documentation.
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.
Case for airlines: In certain cases involving airline expenses, the invoice concept 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 2 taxes, but the total is not applied to all the total, in this case, must be split the line (one by each tax). To this, must be added the label "Is Airline" in the supplier.
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 to True a system parameter named l10n_edi_hr_expense.restrict_product_search. 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.
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. It automatically calculates the IEPS using a standard formula and creates an additional expense line to correctly reflect it in the accounting.
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 IVA).
This means the subsequent taxes IE and IEPS are linked to the primary taxes with IDs 1 and 2.
- - Note: 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.
Advance Payments Handling - Merge Expenses: Supports advance payments by employees when suppliers request prepayment. When the CFDI is received later, the new expense can be merged with the original one using the Merge Expense feature, which will be explained below..
- Note: Debug mode must be enabled to configure system parameters.
Journal Configuration for Employees
Since this module manages employees’ reimbursements as petty cash replenishments, it requires a journal for each employee who makes expenses.
This module provides an automated action to create a journal whenever an employee is created. Such action, named hr_expense: Auto create journal on all employees is disabled by default. You may enable it, or create all journals yourself.
If you choose to use the automated action, you may also configure an account to be used as template, so that the created journal's debit/credit account takes its code, by setting the config parameter l10n_edi_hr_expense.template_account_employee with the desired account ID. If you choose to create the journals manually, you may do so configuring them as follows:
- Journal Name: This should be a representative name that identifies the employee, e.g. Expenses of MARIA OLIVIA MARTINEZ SAGAZ
- Type: Cash or Bank, accordingly
- Cash account: The wage account which the employee is paid from.
Then, edit the involved employee, and under the tab Work Information set the field Journal with the journal just created.
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 RFC in the CFDI that doesn't match any existing partner, it creates one and assigns this tag to indicate its origin (this tag should not be added manually).
Create Invoices Draft: When this tag is present on a vendor, invoices generated from expenses are created in draft state, allowing manual adjustments (e.g., changes to amounts or taxes) before validation.
- Note: This tag should only be used with proper authorization, as ideally all invoices should be generated directly from CFDIs without manual intervention.
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 are automatically grouped and a report is generated and validated.
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. For example, a store like Oxxo may not need this tag even if purchases are made, since it's not a formal supplier.
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).
Autogenerate expense payments: When a vendor has this tag, vendor bills generated from expenses will be automatically paid as soon as they are posted, regardless of the payment mode selected.
Usage
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. Remember that it is necessary that the employee has already configured an associated journal (as was described in Journal Configuration for Employees).
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.
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.
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.
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
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.
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.
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