Automation · Collections and receivables
Create a Siigo electronic invoice with approval before sending it to DIAN
Verify the customer, products, and Siigo catalogs, show the summary, and create the invoice only after new human approval. Read the actual DIAN status.
How do I create an electronic invoice in Siigo without sending it to DIAN before review?
From the Meteor desk, the Met verifies an existing active customer, every product by code, and the actual document, sales rep, tax, and payment catalogs. It uses only an automatically numbered electronic document that requires neither a per-item rep nor a cost center. It then shows every field, ends the turn, and waits for explicit approval in a new message. That approval enables confirmar set to true. The initial request, silence, and the text "true" do not. CO is an administrative precondition because these tools do not expose the country or detect a mistaken configuration. enviar_dian is a separate choice: true requests filing, and the Met reports the Draft, Accepted, or Rejected status returned by Siigo. The task is manual and does not run from a channel Met.
Where it applies: Colombia. This recipe uses Colombia's electronic invoice contract and the DIAN statuses documented by Siigo. It does not present them as equivalent to Mexican CFDI.
What starts it
When someone asks for it
A person starts the task from the desk and supplies the sale to invoice. The Met prepares and shows the summary, but creation remains stopped until an explicit approval arrives in a later message. If the customer, rep, document, line, payment, or filing choice changes, it shows the complete summary again and asks for fresh approval.
A manual task: someone on the team runs it with a button, or asks the Met for it in chat.
Who runs it
Billing Met for Siigo Colombia
Finance and operations team
It supports an internal operator from the web platform. It separates preparation from the fiscal write, lets a person review the concrete document, and preserves the status returned by Siigo as the source of truth instead of turning a filing request into invented acceptance.
What you need connected
- Siigo Collect and manage
6 steps · 6 tools
The procedure, step by step
Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.
- 1
Verify the customer and check that the invoice does not exist
The Met searches for the exact tax ID and accepts only an active customer record, with the branch that will be used. This recipe does not register parties. If the customer is missing, someone creates and validates it in Siigo before resuming. It also lists the customer's invoices on the applicable date, walking every needed page, to detect a prior issue with the same data. A match is read and handed to the operator rather than duplicated by reflex.
- 2
Read every product with its actual tax treatment
Every line starts from an existing code, never an approximate name. The lookup returns prices, taxes, tax classification, and whether the configured price includes tax. This recipe uses the pre-tax unit price accepted by the handler. If the operation has only a tax-inclusive price, it stops for a person to establish the correct value. An incomplete name sweep leads to a request for the code, not a claim that the product does not exist.
- 3
Resolve document, rep, taxes, and payments from catalogs
For the document, the Met queries FV and requires it to be active, electronic, automatically numbered, with vendedor_por_item false and centro_costo_obligatorio false. The sales rep must also be active. Tax identifiers come from the catalog, and payment methods are queried with catalogo formas_pago and the published input tipo_documento="FV". When a payment requires a due date, it preserves the YYYY-MM-DD value. It keeps the exact selected id as documento_id, which must be a positive integer; there is no fallback to the first FV. No identifier or sequence comes from a label.
- 4
Show the complete document and end the turn
Before writing, the Met shows customer and branch, document type and its documento_id, rep, date, every code with quantity, price, and taxes, every payment with value and due date, the operation's expected total, and the separate choices to file with DIAN and email the invoice. It then stops. The original request does not approve this summary. A new, explicit message is required. A question, silence, or ambiguous reply leaves the invoice uncreated. Any change replaces the summary and invalidates earlier approval.
- 5
Create once and read the status Siigo returns
Only after the new yes does the Met call siigo_crear_factura with confirmar as the literal boolean true, the required sales rep, and the approved documento_id as a positive integer. These values are validated before any request and the tool never selects a document automatically. confirmar is never forwarded to Siigo. When included, enviar_dian and enviar_email must be literal booleans; strings, 1, and objects are rejected before the network. enviar_dian is true only when that decision was approved too. The Met then reads the created id and reports number, total, and status: Draft is saved without filing and with no CUFE; Accepted is accepted by DIAN; Rejected was sent but rejected and needs correction and resubmission in Siigo Nube.
- 6
Reconcile an uncertain response without repeating the invoice
When creation returns posiblemente_creada, the Met does not call the write again. It lists invoices by customer and date, walks every applicable page, and reads candidates to compare customer, date, rep, lines, payments, and total. Even when no match appears, it does not retry automatically. It gives the evidence to the operator to review the sequence and status in Siigo Nube. A second invoice requires a later human decision, never a technical retry.
Before you start
What you need ready
The Met solves none of these for you. If one is missing, the automation stops there.
-
A Siigo Nube Colombia account with API access
The administrator generates the username, access key, and Partner-Id in Settings, Partners and integrations, Integration credentials for digital platforms, Add application. Configure the integration as CO; this recipe does not blend in the Mexican contract. This is an administrative check because the recipe tools do not return whether the connector uses CO or MX.
-
Existing customer, products, sales rep, and tax configuration
Keep the customer and branch, coded products and tax treatment, sales rep, taxes, and FV payment methods active in Siigo. The recipe reads them but does not create customers, products, or accounting configuration.
-
An electronic document compatible with this recipe
Configure an active, electronic, automatically numbered FV type in Siigo. It must use one sales rep for the invoice and require no cost center. The Met keeps the selected id as a positive-integer documento_id and includes it in the approval. Handle special configurations in Siigo.
The limits
What this automation does NOT solve
Better said here than discovered halfway through the rollout.
-
It does not detect a connector mistakenly configured as MX. The country lives in the credential and these six tools do not expose it. An administrator must confirm CO first.
-
It does not run from WhatsApp, web chat, Instagram, or Messenger. The connector blocks the fiscal tool when the request carries channel context. Operate this recipe from the web platform.
-
It does not create or update customers. It uses an already verified active tax ID and branch; registration and fiscal data corrections happen outside this flow.
-
It does not cover manual numbering, per-item reps, or documents requiring a cost center. It does not guess sequence numbers; the automatic numbering configured in Siigo controls issuance.
-
It does not turn a tax-inclusive price into a pre-tax price or invent taxes. If the product record does not provide a value compatible with the current input, the operator resolves it.
-
It does not claim that enviar_dian set to true means Accepted. It reports Draft, Accepted, or Rejected from Siigo and leaves rejection correction in Siigo Nube.
-
It does not download or return a PDF link. Siigo offers the PDF through a separate endpoint this connector does not implement. The operator opens the document in Siigo Nube.
-
It does not retry an ambiguous creation automatically, even when queries show no match. An uncertain response may hide an existing invoice, and duplicating it consumes another sequence.
FAQ
Questions about this automation
The first request does not contain the evidence to approve. The second message responds to the customer, rep, document, date, lines, payments, expected total, and DIAN decision the Met just showed. The handler requires the literal boolean true. Missing, false, and the text "true" are rejected before any network request.
No. It means filing was requested. Draft is saved without filing and with no CUFE, Accepted means DIAN accepted it, and Rejected means it was sent but rejected. The Met reads the status returned by Siigo rather than inferring Accepted from the input.
The recipe reports that status and stops. Siigo's documentation directs correction and resubmission from Siigo Nube. It does not change data or reissue automatically because that can produce another fiscal document.
No. The customer must exist, be active, and have the correct branch before invoice preparation. Registration happens in Siigo or a separate flow, and the record is then verified here again.
In Siigo Nube. The API has a separate operation that returns the PDF as base64, but the current connector does not expose it. This recipe's lookup returns data and fiscal status, not a file or URL.
It treats the outcome as possibly created, lists the customer's invoices for that date across all applicable pages, and reads every candidate. It never retries automatically, even with no match. The operator reviews the sequence in Siigo.
Keep going
Other automations built on the same tools
Sales and quoting
From the question to a signed quote, without leaving WhatsApp
How do I send a customer a formal Siigo quote over WhatsApp without opening the system?
Finance and operations
- Starts:
- when the customer writes
- Steps:
- 6, with 11 real tools
- Needs:
- Siigo · Meteor CRM
Collections and receivables
Charge inside the conversation with a Mercado Pago link
How do I charge over WhatsApp without sending people to another app or asking for card details?
Sales
- Starts:
- when the customer writes
- Steps:
- 6, with 11 real tools
- Needs:
- Mercado Pago · Meteor CRM
Collections and receivables
Collect overdue invoices over WhatsApp without chasing anyone by hand
How do I collect overdue invoices over WhatsApp without reviewing the ledger by hand?
Finance and operations
- Starts:
- at a set time
- Steps:
- 5, with 8 real tools
- Needs:
- Alegra · Meteor CRM
Collections and receivables
Charge by PSE and Nequi inside the conversation, with Wompi
How do I charge by PSE or Nequi from WhatsApp without pulling the customer out of the chat?
Sales
- Starts:
- when the customer writes
- Steps:
- 5, with 10 real tools
- Needs:
- Wompi · Meteor CRM
Want this automation running on your own data?
We will show it to you with your accounts connected, not with a canned demo.