How to Integrate Your Collections System with Peru's SIAF

If your collections system —cashier, billing, treasury— already issues receipts and validates identity against RENIEC, the next question is almost always: how do I connect this to the SIAF? The answer surprises anyone coming from RENIEC, SUNAT or PIDE integrations: the SIAF is not an API you consume in real time. It's the official system where the Peruvian State records its revenue and expenses, and your system —however well built— doesn't talk to it directly. This is the honest guide: what the SIAF is, why integrating with it is different from everything else we've written about the Peruvian State, and how we designed that piece in the central cashier of a national university.

What is the SIAF, and why does your system need to talk to it?

The SIAF (Sistema Integrado de Administración Financiera del Sector Público) is Peru's official system, run by the MEF (Ministry of Economy and Finance), where every public entity records its budgetary, financial and asset-related operations. If your system collects money on behalf of a public entity, that revenue has to land there — it's the State's source of truth, not an option.

SIAF-SP integrates each entity's budgetary, accounting and treasury processes into a single system: an Administrative module, an Accounting module, a Budget Execution module, a Reconciliation module, and more. Since 2025-2026 the MEF has been migrating operations to SIAF WEB, with fully online execution of budget, logistics, accounting and treasury — but the underlying principle doesn't change: it's the central registry, not a piece you operate.

The most common misconception: the SIAF is not an API

Unlike RENIEC, SUNAT or the services exposed through the PIDE, the SIAF has no public catalog of web services you consume in real time. It's primarily an application —now migrating to SIAF WEB— where an authorized operator at your entity records the operations, with file-upload interfaces available for some modules.

This changes the whole project design. With RENIEC or PIDE, the technical goal is to open a connection and consume a service. With the SIAF, the goal is different: your system has to produce, in the correct format, everything the SIAF operator needs to record the collection — without your team reconciling it by hand in Excel at the end of every month. The SIAF isn't part of the PIDE's standard catalog; it's a separate system, under the MEF's own governance.

How collections get recorded: Recognized → Collected

The SIAF splits revenue into two moments that are not the same: first what was recognized (the collection right), and later what was collected (the money that actually reached the bank). Your cashier system produces the source documents for both.

Recognized revenue is backed by the Recibo de Ingreso and the daily cashier summary; collected revenue, by the bank deposit slip. A well-designed cashier system —like the one we built for a national university— already generates both documents as part of its normal operation: all that's missing is producing them in the format and at the moment the SIAF operator needs to record them.

What reports come out of the SIAF

What gets recorded in the SIAF doesn't stay there: it feeds three MEF directorates that consolidate the country's financial execution — Public Budget, Public Treasury and Public Accounting.

For your entity, this translates into a concrete requirement: the reports your system produces —daily settlements, revenue by funding source, bank reconciliation— have to match what ends up recorded in the SIAF. If they don't match, the SIAF doesn't fix that; your system's design has to prevent it, delivering Treasury-ready reports from day one.

How we design the real integration

Your cashier system is the operational source of truth — it issues the receipt, validates against RENIEC in real time, controls the sequence number — and the SIAF receives that information periodically, not instantly. Designing for that difference is the part you can't improvise.

In the central cashier system for UNJFSC that we built, every receipt is issued with a unique sequence number, validated in real time against RENIEC, and the system generates a consolidated end-of-day summary that the Treasury office uses to record the collection in the SIAF — with no manual recounting. The integration doesn't live in an endpoint: it lives in the right data reaching the right person, in the right format, at the right time.

Common mistakes when connecting your system to the SIAF

Collections projects almost always stall for the same reasons: assuming the SIAF works like RENIEC, or leaving reconciliation for the end. Neither is a code problem.

How we do it

We build collections and cashier systems that produce, without manual work, everything Treasury needs to record in the SIAF — with RENIEC validation, a unique sequence number and bank reconciliation built in from the design.

We know the full flow because we built it for the public sector: from the RENIEC and systems integration to the report your Treasury office uses to close the month. If your entity collects revenue and needs it to match the SIAF without reconciling by hand, let's talk.

In summary

The SIAF isn't an API you consume: it's the State's official registry, and your collections system is what produces the source documents —Recibo de Ingreso, daily summary, deposit slip— that an authorized operator records there, increasingly through SIAF WEB. Design your system as the operational source of truth, deliver Treasury-ready reports and validate every receipt against RENIEC. Done well, your collections stop being reconciled by hand and start matching on their own.