Electronic Invoicing for AI Agents under SRI Ecuador: XAdES-BES & SOAP

SRI_GATEWAY: CONNECTED // XADES_SIGNATURE_OK

Integrating electronic invoicing with the SRI in Ecuador is usually a bureaucratic and technical headache. When you try to have an Artificial Intelligence agent (like a WhatsApp bot or a local orchestrator) issue invoices, the problem multiplies: LLMs cannot natively handle complex digital signatures or SOAP requests.

The solution I implemented in mcp-sri consists of completely decoupling these responsibilities into a modular, stateless service.

The XAdES-BES Signature Problem

The SRI requires each electronic invoice to be digitally signed using a PKCS#12 (.p12) certificate under the XAdES-BES (XML Advanced Electronic Signatures) standard. This involves:

Generating an XML structure in the strict SRI v2.1.0 format.
Signing it using asymmetric cryptography algorithms (usually RSA-SHA256).
Preserving XML namespace integrity and canonicalization.

Doing this directly in Python with native libraries is highly error-prone due to cryptography dependency incompatibilities and XML signature formatting issues across different operating systems.

Decoupled Signing Architecture

To guarantee absolute stability, I decided to split the process into a Java-based signing microservice (using Apache Santuario and Bouncy Castle) and a Python-based MCP server that exposes the tools to the agent.

[AI Agent]
    │
    ▼ (Generate XML v2.1.0)
[mcp-sri (Python)] ───► [Signing Microservice (Java)] (Reads .p12 certificate)
    │                                 │
    │ ◄───────────────────────────────┘ (Returns Signed XAdES-BES XML)
    ▼
[SRI SOAP Reception / Authorization]

1. XML and Access Key Generation

The Python MCP server takes the structured input data (items, client, amounts) and constructs the base XML. Simultaneously, it generates the 49-digit access key required by the SRI using the Modulo 11 algorithm.

2. Deterministic XAdES-BES Signing

The unsigned XML is sent via an HTTP POST request to the local Java microservice. This service loads the .p12 certificate from memory or disk, performs the precise digital signing, and returns the fully signed and structured XML without adding unnecessary overhead.

3. Offline SOAP Transport

The SRI exposes two SOAP-based (Simple Object Access Protocol) web services:

RecepcionComprobantesOffline: To submit the signed file.
AutorizacionComprobantesOffline: To query whether the document was legally authorized.

The MCP server performs these SOAP requests asynchronously, parsing the responses and handling retries in case of SRI server downtime (an extremely common issue).

Agent Abstraction

The beauty of this design is that all this complexity is reduced to a single tool exposed to the LLM:

{
  "name": "flujo_completo_factura",
  "arguments": {
    "secuencial": "42",
    "tipo_identificacion_comprador": "RUC",
    "identificacion_comprador": "0993396918001",
    "razon_social_comprador": "UPGRADE-EC S.A.S.",
    "email_comprador": "[email protected]",
    "items": [
      {
        "mainCode": "SRV-001",
        "description": "Enterprise AI Agent Development",
        "quantity": 1,
        "unitPrice": 1500.00
      }
    ]
  }
}

The agent runs the workflow and receives the final state back: AUTORIZADO, the access key, the signed XML, and the RIDE physical representation. No manual parsing, no SOAP handling. Clean engineering to enable financial autonomy for agents.