The Deduction That Depends on Your Warehouse
In most countries a compliance obligation is something your finance team discharges. Colombia puts one of them at a loading bay — and makes your ability to deduct a purchase depend on whether anybody told the supplier the goods arrived.
Ask where compliance happens in a business and almost everybody points at the same room. Colombia is the exception worth knowing about, because one of its obligations is discharged by a person in a warehouse with a clipboard, and the money it decides is yours rather than your supplier's.
The rule is in article 616-1 of the Estatuto Tributario. Where a purchase is on credit, or where any payment term is granted, the buyer must confirm two things by electronic message back to the supplier: that the invoice was received, and that the goods or services were received. Until both are sent, that invoice is not support for the buyer's costs, deductions or input VAT. Not the supplier's position — the buyer's.
Read that twice, because the instinct is to file it under e-invoicing and move on. E-invoicing is what your supplier does before the document reaches you, and by the time it arrives it is already valid. This is the step after that, it is yours, and nothing about it is automatic.
The document everybody improvises is the one the law leans on
We have argued elsewhere that in a three-way match, the invoice is never the missing document — the purchase order and the goods receipt are the two that get improvised, because they are the two you were supposed to create yourself. The invoice always arrives, in triplicate, chased weekly, because the party who benefits from it wrote it.
Colombia takes the more improvised of those two records and makes it load-bearing. The goods receipt stops being an internal control you keep for your own protection and becomes a compliance artefact that has to leave the building. A signature on a delivery note in a folder at the gate does not do that.
| The record | Who writes it | What Colombia asks of it |
|---|---|---|
| The purchase order | You | Nothing directly. It remains your own control. |
| The supplier's invoice | Them, cleared by the authority before you see it | That you acknowledge receiving it, electronically, back to them. |
| The goods receipt | You, often on paper, often at a gate | That you acknowledge the goods arrived, electronically, back to them — and your deduction waits on it. |
The control you kept for your own benefit is now the step the deduction waits on. Nobody in the warehouse has been told.
Two messages, and they are not the same message
It is tempting to collapse these into one acknowledgement, and systems that try tend to send the wrong one. They are about different events, they become true at different moments, and in a great many purchases they are weeks apart.
-
That the invoice arrived
A statement about a document. It becomes true when the electronic invoice reaches you, which for a credit purchase is frequently before anything physical has moved. It is the easier of the two, and it is the one a system with an inbox can plausibly automate.
-
That the goods or services arrived
A statement about the world. It becomes true when a delivery is accepted at a location, by a person, in a quantity that may not match what was ordered. No inbox knows this. The only system that can know it is the one your receiving process actually runs in — which is the argument for those being the same system.
The procedural detail sits in DIAN's consolidated resolution — Resolución 227 de 2025, article 1.5.4.9.1, which is where the rule formerly published as Resolución 000165 de 2023 now lives. We are deliberately not printing a number of days for either message here: the statute defers the timing to the rules that regulate the matter and to a technical annex, and we have not read the annex. A vendor page that gives you a confident deadline it has not verified is telling you something worse than nothing.
What ours does, since we are the ones raising it
We record the second event and can send neither message. Receiving is captured against the purchase order — the item, the quantity, the location, the moment — so the fact the law cares about is already in the system, dated, and attached to the right document. What does not exist is any outbound message to a supplier at all. There is one acknowledgement timestamp in our purchasing records and it runs the other way: it marks the supplier confirming our order. That is a sensible thing to track and it is the exact mirror of what is needed here. Published in the same words on our Colombia page.
Why this fails quietly, which is the reason to read it early
Every failure mode we write about on this site has the same shape and this is the purest example of it. The order was raised correctly. It was approved by the right person. The goods arrived and were counted. The invoice matched. Somebody paid it on time. Nothing on any screen is red, and the deduction is not available.
There is no error state for an obligation nobody was prompted to discharge. The first sign is a tax position at the end of a period that is worse than the ledger implied, and by then the purchases in question are months old and the acknowledgements they needed are not retrospective in any way a person can rescue on a Friday afternoon.
What a buyer can actually check
Four questions, and the second one is where most systems stop
Where in the product does receiving goods produce something that leaves the building?
What you will hear
A screen, an integration, or a description of a separate portal.
How to read it
If it is a separate portal, that portal is your compliance system and the product you are being shown is a record kept alongside it. That can be a perfectly good arrangement — but you should choose it rather than discover it.
Are the two acknowledgements separate, and can they happen weeks apart?
What you will hear
Often a single "confirm" action.
How to read it
One action for two events means the system is guessing which one you meant. On a credit purchase where the invoice precedes the delivery, sending both at once is sending one of them before it is true.
What does the system know about the supplier's invoice — the lines, the tax, the reference?
What you will hear
Sometimes a stored file.
How to read it
A file is not a document. If nothing reads it, then the acknowledgement, the input credit and the line comparison are all being done by a person with the file open, and the system is a filing cabinet with a search box.
Show me the report of purchases received but not yet acknowledged.
What you will hear
This is the one that decides it.
How to read it
If that report exists, the vendor has modelled the obligation. If it has to be described rather than shown, they have read about this market rather than met it.
What AWRA OpsHub does today
- Receiving recorded against the purchase order — the item, the quantity, the location and the moment. This is the event the rule is about, and it is captured.
- Order-to-receipt reconciliation with your own quantity and price tolerances, so a short delivery or a moved price is an exception with a name on it.
- Purchase approvals that refuse, with the decision, the person and the time recorded against the document.
What it does not do
- Neither acknowledgement message can be sent. There is no outbound communication to a supplier anywhere in the product. This is the whole of it and there is no partial version.
- Nothing reads a supplier's electronic invoice. It is held as a file, and our own reconciliation reports the billing comparison as not captured rather than claiming a match it cannot make.
- We hold how much tax was on a purchase, never the rate that produced it — so an input figure can be totalled and not recomputed. That is a schema problem we have written about before, and it is the honest scope of the gap rather than the wider claim that there is no tax on the buying side, which is not true.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If the seam to a clearance provider, a supplier invoice that can be read, a limit that is not an amount, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Which end of the document you stand at, and what the limit is written in
Three builds cover most of what this region exposes, and the first is a seam rather than a system. Document exchange with the authority runs through a role somebody is accredited for, so what we build is the two-way join to the provider you pick — our document handed over in the shape they expect, and the reference, status and any acknowledgement written straight back onto our record, which is what turns "which of ours are not yet cleared" into a report rather than a reconstruction. Second, reading a supplier's electronic invoice into lines that carry tax, so the purchase side holds a rate and not only an amount. Third, a limit expressed as a multiple of an index unit rather than as a sum of money, with something that actually reads the unit when it is revalued. All three are data-model changes rather than settings, and we would quote them as such.
Local payment rails, and obligations that fall on the buyer
Statement feeds and local payment rails wired into the Payments Register, alongside the buyer-side obligations this region is unusual for — an acknowledgement generated from a receiving event and transmitted, and a report of purchases received but not yet acknowledged. Receiving against the order already runs; the outbound half is the buildable part on top of it.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A local payroll engine with income tax tables and social security contributions computed on live employee records, producing returns in the layout your authority expects rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe short version
If you buy on credit terms in Colombia, write down who in your organisation would send these two messages today, and when. If the answer is a person logging into a portal from a spreadsheet of deliveries, that is a real answer and it works — right up to the volume where it does not, which arrives without warning. The question to put to any vendor is not whether they support electronic invoicing, because that is your supplier's side and it is already done by the time the document reaches you. It is whether receiving goods in their system produces anything that leaves the building.
