What's the difference between an XML reader and received invoice management?
The same invoice can go through four different tasks. Separate them before choosing a tool or commissioning custom development.
An electronic XML invoice reader turns a technical file into a readable view. It can also extract the supplier, dates, taxes, line items, and total. It's enough when someone reviews a few documents and records them manually.
Received invoice management stores those documents, prevents duplicates, shows statuses, assigns owners, and sends information to the accounting or purchasing system. It can include buyer electronic events when required. Not every reader handles those tasks.
In Colombia, XML follows a technical structure defined by DIAN. The Electronic Sales Invoice Technical Annex version 1.9 lets you extract structured fields with verifiable rules. You don't need an AI model to interpret those fields.
Reading and validating are also different tasks. DIAN lets you check a document and its validation using CUFE data in its electronic invoicing system. That check provides evidence a local viewer can't provide. DIAN states that validation occurs in real time, except for contingency documents, before it guarantees tax effects. See DIAN's verification guide to confirm a document's status.
What evidence does each task provide for a received invoice?
A tool can cover one or several layers. Requiring all of them from a simple reader adds cost without fixing the actual process.
| Task | What it does | Evidence it provides | When it's enough |
|---|---|---|---|
| Read XML | Shows the file as an invoice | Fields contained in the XML | Manual review of a few documents |
| Extract data | Stores fields and line items | Data ready for rules | Accounting or purchasing intake |
| Check DIAN | Looks up the CUFE and its status | Document validation | Tax control and audit |
| Manage events | Tracks buyer messages | Receipt traceability | Credit purchases or payment terms |
| Accounting workflow | Reviews and sends data to the ERP | Approval and accrual | Recurring supplier volume |
An invoice's status, electronic messages, and internal approval are separate records. Keep them separate, even if they appear on the same screen.
What do you need to decide between a reader and received invoice management?
This decision tree helps you avoid starting with an oversized platform or falling short with a file viewer.
- Do you only need to open a few XML files? Use an electronic XML invoice reader that shows the issuer, buyer, items, taxes, total, and CUFE. Save the original XML beside the readable view.
- Do you need to load recurring data? Implement an XML parser with rules to extract the tax ID, number, date, subtotal, taxes, total, currency, purchase order, and line items. Add validations between totals and items.
- Do you need to prove validation or manage credit? Separate the DIAN check from file reading. For credit transactions or payment terms, track invoice receipt and receipt of goods or services. Article 616-1 requires these messages as formal support for costs, deductions, and creditable taxes. After a July 2025 ruling, there is no mandatory legal deadline, but the documentation requirement remains. DIAN Concept 15517 of 2025 explains this criterion. This doesn't replace legal or tax advice.
- Does your team process a steady flow? You need received invoice management. Connect email, folders, a supplier portal, or an API; record statuses; send exceptions for review; and deliver approved data to the ERP. An API integration reduces forwarded files and manual entries.
What does a practical received invoice architecture look like?
Cost and timeline depend on input channels, volume, receiving systems, and exception rules. These layers let you build only what you need.
Input
Separate XML, PDF, and email
The system receives XML files and attachments, stores the original file, and links each document to its email or incoming channel. It doesn't assume a PDF replaces the XML.
Foundation for traceability
Rules
XML parser and deterministic controls
The parser extracts defined data. Rules compare the subtotal, taxes, and total; detect a repeated CUFE; and flag a supplier or purchase order mismatch.
Foundation for structured data
Statuses
Validation, events, and approval
Each status keeps its source: tax check, electronic message, purchasing review, or accounting approval. Users can see what's missing without inferring it from the XML.
Foundation for operations
Output
ERP, accounting, or review queue
Complete invoices move to the destination system. Invoices with differences go to a queue with the reason and the data a person needs to review.
Foundation for exceptions
When does AI make sense for received invoice processing?
AI helps when there is ambiguity. It doesn't improve a field already defined in the XML.
Illustrative example: a Colombian company receives supplier invoices in a shared inbox. The system takes the XML and extracts the tax ID, CUFE, date, taxes, and total. It then compares the total with the purchase order and looks for duplicates by CUFE, invoice number, and supplier. Invoices without differences go to accounting review. The rest are flagged with a specific reason.
AI can classify an email when the cost center is unclear. It can also read a payment request, a scanned document, or a supplier's written note. Before using it, we measure how many cases become exceptions and whether its classification improves the team's work. This differs from using AI to read every XML field.
In Mexico, separating these tasks also helps. SAT lets users check and retrieve tax receipts, while its metadata includes the fiscal folio, RFC, total, effect, and status. Metadata helps with control and search. The XML retains the receipt's structured detail. SAT describes the available lookup, retrieval, and metadata. To automate this workflow, start with AI automation only when exceptions need interpretation.
