How to integrate SUNAT e-invoicing into your system

In Peru, issuing electronic receipts is no longer optional: since 2025 practically the entire General Regime and the MYPE Tax Regime is required to do so, and failing to issue carries a fine of 50% of the UIT (around S/ 2,750 in 2026) the first time. The serious question isn’t whether you invoice electronically, but how that connects to your operation. If your team re-keys every sale into a separate portal, you’re paying twice. This guide explains the modalities, the OSE vs. direct decision, the technical standard, and how to integrate invoicing so that your system invoices on its own — from the experience of having connected it with SAP Business One in a real case.

First: the invoice isn’t valid until SUNAT accepts it

Issuing isn’t invoicing. An electronic receipt only has tax validity when SUNAT —or an OSE— returns a CDR (Acknowledgement of Receipt) with an “accepted” status. Rejected or with observations, it’s void. Your integration has to handle that response, not just send the XML and assume it arrived.

This is the most expensive misunderstanding. The real flow of an electronic receipt is a round trip: your system generates and signs the XML, sends it, and receives back a CDR that can be accepted, rejected, or accepted with observations. Only the accepted one grants tax validity. A serious integration doesn’t end when it sends the document: it ends when it reads the CDR, stores it, and acts on the result. Skipping that part is invoicing blind.

The 4 SEE modalities (and which one you need)

SUNAT offers four issuance systems: SEE-SOL (free web portal), SEE-Facturador (desktop app), SEE-Del Contribuyente (your own system with a digital certificate) and SEE-OSE (through an authorized operator). To integrate with your system or ERP, the ones that matter are the last two.

SEE-SOL and the Facturador solve manual issuance without touching your system — they work for low volumes, but they force you to key data in. The ones that connect to your operation are Del Contribuyente (your system talks directly to SUNAT) and OSE (your system talks to an operator that validates on your behalf).

OSE or direct issuance: the key decision

With SEE-Del Contribuyente your system sends the XML directly to SUNAT; with SEE-OSE it sends it to an operator that validates it and returns the CDR. The OSE is mandatory for PRICOS with income ≥ 300 UIT since July 2025, and for many it’s simpler; direct issuance gives more control. Both integrate via web service.

An OSE (Electronic Services Operator) doesn’t issue your receipts: it validates them computationally and returns the CDR to you, outsourcing the most delicate part. It’s mandatory for large taxpayers with high income, and convenient for everyone else. Direct issuance (Del Contribuyente) gives you more control and avoids the operator’s monthly cost, in exchange for taking on validation yourself. The good news: in both cases, what your team builds or contracts is the API integration — you don’t have to choose between integrating or not, but with whom.

The technical standard: UBL 2.1, digital signature and CDR

The official format is XML UBL 2.1, in UTF-8, with a digital signature (X.509 v3 certificate, SHA-256 hash) and a printed representation in PDF with a QR code. It’s not optional: a malformed or improperly signed XML is rejected by SUNAT with an error CDR.

Here’s the detail that makes “just sending an invoice” more work than it seems. The receipt travels as an XML under the international UBL 2.1 standard, digitally signed to guarantee its integrity, and accompanied by a printed representation with a QR code for verification. Every field has rules; a formatting or signature error translates into a rejection CDR. That’s why prior validation —before sending— is part of the work, not an extra.

The real value: making your system invoice on its own

The difference between buying an invoicing product and integrating it into your system is that with the latter no one re-keys anything: the sale, the enrollment, or the order generates the receipt automatically, with its data, and stores the CDR. What saves work is the integration, not the issuance.

An invoicing tool your cashier operates separately handles the formality, but leaves the double work: someone copies each operation from the sales system into the invoicing one. Integration eliminates that step. For the enrollment system of a club with 50,000+ members we connected every transaction with SAP Business One so that invoicing came out on its own: the member enrolls and the receipt is issued, validated, and archived without anyone keying it twice. That’s the point — and it’s the integration line item that delivers the return, not the issuance itself.

OSE, off-the-shelf or custom: what to buy and what to build

An OSE or an off-the-shelf invoicing tool handles standard issuance well — it’s a commodity, don’t reinvent it. What gets built custom is the integration: how your specific operation generates the receipt and what it does with the CDR. The rule: buy the issuance, integrate the flow.

There’s no point building your own OSE or your own signing engine: that already exists, mature and cheap, and competing against it is throwing money away — the same logic as custom vs. off-the-shelf software. What no product comes with is your flow: how your process triggers the receipt, with what data, with what rules, and what your system does when the CDR arrives with observations. That’s what gets built custom and what really saves you hours.

Common mistakes when integrating invoicing

Almost every problem comes from treating issuance as “send and done”: not handling the CDR, not validating the XML before sending it, or not planning for what happens when SUNAT or the OSE doesn’t respond. None of them is hard — but skipping them breaks invoicing exactly when it hurts most.

How we do it

We integrate invoicing into the real business flow. For a club with 50,000+ members we connected enrollments with SAP Business One so that every transaction invoices on its own. We help you choose OSE or direct issuance and build the integration tailored to your operation.

We don’t sell an OSE or an invoicing tool: we integrate whichever suits you — or direct issuance — with the system you already use, so that invoicing stops being a manual step and becomes part of the flow. We choose the modality with you, solve the technical part (UBL 2.1, signature, CDR, contingency), and connect it to your real operation.

In short

Electronic invoicing is already mandatory; what you decide is how it connects to your operation. Remember that the invoice isn’t valid until the accepted CDR, choose between OSE and direct issuance based on your size and your need for control, respect the UBL 2.1 standard with its signature, and —above all— integrate issuance into the business flow so no one keys data twice. Buy the issuance, which is a commodity; build the integration, which is where the savings are.