Service statusStatus ESEN
Sales and support 442 138 8102 Request a demo
Two Fisher Platform modules

Issue CFDI 4.0 invoices and keep your SAT tax books without leaving your system.

E-invoicing stamps your invoices, credit notes and payments with your PAC. SAT tax accounting pulls issued and received documents from the SAT with your e.firma, calculates your provisional payments, prepares the DIOT and builds the electronic accounting. One CFDI register for the accountant and for the company.

See it in action How invoicing works
  • CFDI 4.0 with payment complement 2.0
  • SAT bulk download with encrypted e.firma
  • A working paper that explains every line
admin/einvoice/cfdi
Issued CFDI. Invoices, REP, credit notes and global invoice with their tax folio. Fictitious demo data.
19regimes in the SAT catalog, open to more
3regimes with provisional payments calculated: RIF, RESICO individuals and 612
2interchangeable PACs: FacturoPorTi and SW Sapien
4SAT cancellation reasons, with replacement
E-invoicing · CFDI 4.0

One button on the invoice and the CFDI comes out stamped

Your invoices, credit notes and payments stay where they are, in Invoicing. The module adds what the SAT requires, with nothing captured twice.

From the invoice

Stamping is just one more step of invoicing

  • Invoices, credit notes and payments: your platform generates and seals the 4.0 XML with the company's CSD and the PAC only stamps it. Switching PAC means switching provider, not system.
  • Your choice of PAC, FacturoPorTi or SW Sapien, with test and production environments. Anything stamped in testing carries the "PRUEBAS · SIN VALIDEZ FISCAL" (test, no tax validity) mark.
  • Checked before stamping: the recipient's RFC, regime, postal code and CFDI use, plus amounts and SAT codes, so the PAC does not reject it.
  • Tax folio (UUID) on the invoice and in the list. An invoice with a valid CFDI can no longer be edited, cancelled or deleted by accident.
  • Stamp on issue (off by default): your ISP's monthly billing and Hosting renewals are stamped automatically, through a queue.
admin/invoicing/invoice/…
The invoice. The CFDI, the pending payment complement notice and the payments, all on the same record.
1

Invoices

The invoice is issued in Invoicing, by hand or from ISP and Hosting.

2

Checked

Recipient, amounts and SAT codes, before calling the PAC.

3

Stamped

Sealed with your CSD, and the PAC returns the stamp.

4

Delivered

XML and PDF with QR code by email and in the customer portal.

5

Collected

If it was on credit, every payment carries its payment complement.

No surprises

Never two stamps, and if something fails you know why

  • The sealed XML is saved before it is sent. If the connection drops, the retry sends the same XML and the PAC answers "already stamped" with the stamp: a second CFDI is never issued.
  • Rejections come with their code and reason. You fix the data on the customer record and it is sealed again.
  • "Unknown" is not "rejected": if there is no confirmation from the PAC, the invoice stays blocked until it is resolved.
  • Cancellation with reason 01 to 04 and replacement in one step (relation 04 and cancellation 01). In production it stays "being cancelled" until the SAT confirms it.
  • Status check at the SAT, XML and PDF download and delivery to the customer, all from the same record.
admin/einvoice/cfdi/…
CFDI record. Data, line items, PAC calls and actions: check, send, replace or cancel.
For you and for your customer

PDF with QR code and XML, one click away or in the portal

  • Printed representation with tax folio, digital seals, the original string of the SAT complement and the verification QR code.
  • Email delivery to the customer's billing email, with the XML and PDF attached.
  • Download in the customer portal: the XML and the PDF, with no need to request them by email.
  • Import a CFDI stamped outside the platform into its invoice, checking that it belongs to the issuer, has the same total and a valid seal.
admin/einvoice/cfdi/…/pdf
CFDI PDF. With QR code, seals and original string. This one carries the test mark because it was stamped in the test environment.
Payment complement 2.0

Every payment on a credit invoice, with its REP

  • "Payments pending complement": every payment on a PPD invoice appears there and one click stamps the REP. If you prefer, it is stamped automatically (automatic REP).
  • Installments with previous balance, amount paid and outstanding balance, and proportional base and VAT, as Annex 20 requires.
  • A payment never carries two REP, a payment with a valid REP cannot be deleted and an invoice with valid REP cannot be cancelled.
  • A PUE invoice carries no REP, and the system tells you so instead of letting you stamp one by mistake.
admin/einvoice/payments
Pending payments. What still needs its REP.
admin/einvoice/cfdi/…
The REP. Installment, previous balance, amount paid and outstanding balance.
General public

Global invoice for over-the-counter sales

  • Bundles into one CFDI the period's collected sales to customers without an RFC, who have no CFDI of their own, under the generic RFC and "PUBLICO EN GENERAL".
  • Periodicity, months and year with the global information the SAT requires; one line item per sale and per rate.
  • A sale cannot be in two global invoices, and a sale included in a valid global invoice cannot be cancelled in Invoicing.
  • With automatic stamping, customers without an RFC are skipped or issued under the generic RFC, depending on the setting you choose.
admin/einvoice/global
Global invoice. The month's sales without an RFC, ready for a single CFDI.
Issuer, CSD and PAC

Your certificate and your provider, safely stored

  • The CSD is checked on upload: that it is a seal certificate and not the e.firma, that the key opens, that it matches the certificate, that it is valid and that the RFC is the issuer's.
  • Key, password and PAC credentials are encrypted with the installation key; they are never shown again and never leave through the API, the log or Bastino.
  • The private key only travels to the PAC to cancel, and only if the PAC supports nothing else (FacturoPorTi), over https and in that call.
  • Each instance stores its own CSD, encrypted with its own key, if you offer the platform to several customers.
  • The issuer screen starts out not granted to anyone: not everybody sees it.
admin/einvoice/issuer
Issuer, CSD and PAC. Issuer data, the certificate with its validity and the stamping provider.
Customers and SAT codes

The data the PAC asks for, where you already have it

  • "Tax data (CFDI)" tab on the customer record: RFC and legal name as on their tax certificate, tax postal code, regime and CFDI use.
  • Product or service codes by rule: depending on the module that issued the invoice, the line item text or the catalog item. The correct codes are decided by the company's accountant.
  • Which Invoicing tax is each SAT tax, and the payment form of each payment method.
  • Searchable SAT catalogs that fill the selectors.
admin/clients/client/…
Customer tax data. With a notice of whether it is complete enough to stamp.
admin/einvoice/keys
SAT codes. Rules by module or by text, taxes and payment forms.
SAT tax accounting

What the SAT already has on your customer, turned into numbers

It starts from their issued and received CFDI. From there come the working paper, the DIOT and the electronic accounting, always from the same source.

1

Downloads

Issued and received from the SAT, or XML, ZIP and metadata by hand.

2

You classify

Deductible, investment or unrelated, with rules you teach once.

3

You calculate

Provisional payments and VAT, with every line explained.

4

You file

The return, the DIOT and the accounting are uploaded to the SAT by a person.

5

You record

With its acknowledgment and a snapshot: if something changes later, it warns you.

Taxpayers and e.firma

Every RFC with its regime and its e.firma under lock

  • Individuals and legal entities (deduced from the RFC) with their regime history and periodicity: several at once and changing over time, such as RIF until one date and RESICO from the next.
  • Catalog of 19 SAT regimes, open so a module can add another with its own calculation.
  • The e.firma is validated on upload (that it is an e.firma and not a CSD, valid and belonging to the taxpayer's RFC) and stored encrypted with AES-256-GCM, in a folder outside the web root. Not a single encrypted byte is in the database.
  • It is never shown or downloaded again: it is replaced, deleted or tested. Notice before it expires.
  • Managing the e.firma and requesting data from the SAT are separate permissions, and the e.firma screen starts out not granted.
admin/fiscal/taxpayers
Taxpayers. Every RFC with its regime, its e.firma and its number of CFDI.
admin/fiscal/efirma
e.firma. Certificate number, expiry and how it is stored. Test certificates.
Bulk download

CFDI from the SAT arrive on their own, without logging in to the portal

  • Issued and received, as XML or metadata, by period or by tax folio (UUID). A long period is split into one request per month.
  • The SAT rules are checked before a request is spent: start date no older than six years, received documents as XML only if valid, and how many times the same period can be requested.
  • A scheduled task asks, downloads and imports the packages on its own, with retries at increasing intervals. "Advance now" if you don't want to wait.
  • Automatic daily metadata (optional) to find out about cancellations.
  • It only talks to the SAT servers, over https and with the destination verified. No e.firma at hand? XML, ZIP or metadata can be uploaded by hand.
admin/fiscal/downloads
SAT downloads. Request a period and follow each request until it is imported.
CFDI register

A register that never duplicates and never overwrites

  • One CFDI per taxpayer and tax folio (UUID): re-importing does not duplicate and another XML with the same UUID does not overwrite the first.
  • Every detail: taxes at voucher and line-item level, withholdings, payments complement 1.0 and 2.0, related CFDI, cancellations and currency with exchange rate.
  • Linked to your ERP: issued documents to your customer by RFC and, if you use E-invoicing, to the CFDI you stamped; received documents to your supplier.
  • Filters by taxpayer, dates, direction, type, payment method, status and counterparty RFC.
admin/fiscal/cfdi
SAT CFDI. Issued and received for each taxpayer, with their status.
admin/fiscal/cfdi/…
CFDI record. A rent receipt with its VAT charged and its income tax and VAT withholdings.
Classification

Received documents classify themselves, and what you set takes priority

  • Every received CFDI comes in classified: deductible, non-deductible, investment or unrelated, with its deductible % and VAT treatment.
  • Rules by issuer RFC, CFDI use, payment form, type, amount or product code. By default, for example, cash payments over $2,000 are non-deductible and uses D01 to D10 are unrelated.
  • What you classify by hand is never overwritten by a rule; "Apply rules" only recalculates the rest.
  • Whatever remains pending shows up as a warning in the working paper, so it doesn't slip by.
admin/fiscal/classification
Classification. By rule or by hand, with the VAT treatment of each received document.
Working paper

Provisional payments with every line explained

  • RIF (621, bimonthly), RESICO individuals (626, monthly) and business and professional activity (612, cumulative for the year), with VAT by rate, creditable proportion and previous credit balance.
  • Cash-flow basis: PUE on its date, PPD on the date of each payment complement, credit notes, cancelled documents left out and foreign currency with its exchange rate.
  • Every line says "how it is calculated" and a button shows the CFDI that add up to it: the amount always matches its detail.
  • Rates, tariffs and caps as data per year, with their legal source, and fixed assets with their depreciation deduction.
  • You record what was filed, original or amended, with its snapshot. If a CFDI of the period is cancelled later, it is flagged "amended return required". Export to Excel (CSV) and PDF.
admin/fiscal/periods/…
Working paper for 612. Every line with its explanation and, on the income and expense lines, the detail button.
admin/fiscal/periods
Periods. What has been filed with its operation number and what is still to be filed.
DIOT

The DIOT comes from the same register, ready to upload

  • It is built from paid received CFDI, with the same cash-flow basis for creditable VAT and the same classification as the working paper.
  • One line per third party with their suggested third-party type and operation type, creditable and non-creditable VAT and withheld VAT.
  • Operations without a CFDI, such as imports and payments to foreign parties, are captured separately.
  • You download the bulk-upload TXT in the SAT format (2025 onward, 54 fields) and record the filed DIOT with its operation number. If something changes later, it warns you.
  • Who must file it is decided by regime and by the taxpayer's parameters.
admin/fiscal/diot/…
The month's DIOT. One line per third party and the button to download the bulk-upload file.
Electronic accounting

Chart of accounts, journal entries and trial balance, without running another system

  • Chart of accounts with the SAT grouping code, with templates by taxpayer type and link accounts.
  • Automatic journal entries from CFDI: income and expenses when collected and paid, credit notes, issued payroll and depreciation. Plus manual entries with their supporting UUIDs.
  • Trial balance with opening balance, debits, credits and closing balance, which warns you if it doesn't balance; general journal, subsidiary ledgers, closing entry and month 13.
  • Every entry carries the CFDI that supports it. "Generate" updates the automatic ones if a CFDI changes or is cancelled, and manual ones are left untouched.
admin/fiscal/journal
Journal entries. Automatic from each CFDI, with their support, and manual when needed.
admin/fiscal/ledger
Trial balance. With the notice of whether it balances and the grouping code of each account.
Annex 24

Validated XML and a record of what you submitted

  • Chart of accounts, trial balance, journal entries and subsidiary ledgers as XML, validated against the SAT schemas and packaged in a ZIP with the name the SAT requires.
  • Monthly calendar with the deadline, the obligation, whether the trial balance matches and the "not submitted (overdue)" notice.
  • You record every submission with its acknowledgment, original or amended. If you change an entry in a month already submitted, that month is flagged "amended submission required".
  • Who submits is decided by the regime and a taxpayer parameter: for example, 612 does and RESICO individuals, in general, do not.
admin/fiscal/econtab
Electronic accounting. Every month with its status, its acknowledgment and its deadline.
Compliance

Built the way the SAT requires, not the way that is convenient

Every piece follows the format or procedure the SAT publishes, and whatever changes each year is data, not code.

CFDI 4.0

XML with original string and SHA-256 with RSA seal, which is re-read and verified before it is sent to the PAC. Amounts are calculated as in Annex 20 and, if they don't match the invoice, it is not stamped.

Payments complement 2.0

Installments, balances and base and VAT per related document, with exchange rate when the payment is not in pesos.

Cancellation with reason

Reasons 01 to 04 with the replacement folio. The request is signed on the platform and stored with its acknowledgment.

Bulk download v1.5

Authentication and requests signed with the e.firma, verification and package download, with the SAT's limitations validated before a request is spent.

Tariffs as data

The RMF Annex 8 tariffs, rates and caps live in per-year tables with their legal source: changing year means adding a table, not releasing a new version.

DIOT

Bulk-upload file per fiscal-year format, with the lines the SAT requires and errors flagged per line before you download it.

Annex 24

Catalog, trial balance, journal entry and subsidiary ledger XML validated against the SAT schemas, with the expected file name and ZIP.

Encrypted keys

e.firma, CSD and PAC credentials encrypted and never returned to the screen, the API or Bastino, with a notice before they expire.

What was filed stays on record

Return, DIOT and trial balance are saved with their operation number or acknowledgment and a snapshot of what was calculated; if it changes later, the system warns you.

Connected to the rest

It is not an island: it is part of your platform

It builds on what Fisher Platform already has, instead of copying it.

Invoicing

Stamp button and tax folio on the invoice and the credit note, folio in the list and locks so that stamped documents cannot be edited, cancelled or deleted by accident.

ISP and Hosting

ISP monthly billing and Hosting renewals can be stamped when issued, through a queue that is not lost if the issue is undone.

Clients

Tax data tab on the customer record and, in SAT tax accounting, the issued CFDI linked to its customer by RFC.

Suppliers

Received CFDI are linked to your supplier by the issuer's RFC, if you use the Suppliers and Purchasing modules.

Customer portal

Your customer downloads the XML and PDF of their stamped invoices without requesting them by email.

Bastino

Check the status of your CFDI and the taxpayers, downloads in progress and counts by period, and classify received documents with a confirmation card. It does not stamp, does not cancel and never touches the e.firma or the CSD.

Actions and filters

Events on stamping and cancelling, and open catalogs of regimes, DIOT formats, accounting templates and stamping providers so another module can add its own.

Notifications

Notice of e.firma expiry and of anything that needs attention, through the channel each person chooses.

Multiple companies

If you offer the platform to several customers, each instance stores its own CSD and its own e.firma, encrypted with its own key.

Stated plainly

What it does and what it doesn't

Better to know before you sign up than to find out afterwards.

Designed with security in mind

SAT keys, stored the way they should be

  • Layered encryption: to open the e.firma you need the database, the server folder and the environment key all at once, plus an optional extra key that can live outside the web server.
  • Only the SAT and PAC servers, through a gateway that checks the destination, follows no redirects and verifies the certificate.
  • XML is read without DTDs or entities and ZIP files with a cap on entries and size, so a malicious file is harmless.
  • Fine-grained, per-screen permissions: view, request from the SAT, upload, classify, close periods, DIOT, accounting and e.firma, each one separately.
What you need to know

The SAT and the PACs set their own conditions

  • You need a PAC and your CSD: the SAT does not allow bulk stamping on your own. You hire FacturoPorTi or SW Sapien, get the CSD from the SAT and start in testing.
  • It does not file for you. The SAT has no API for returns, DIOT or electronic accounting: here it is calculated, the file is generated and what a person filed is recorded.
  • It calculates RIF, RESICO individuals and 612. There are no calculators yet for legal entities (601 on an accrual basis, RESICO legal entities), annual return, INPC adjustment or profit coefficient. Calculations should be reviewed with your accountant.
  • Withholdings: it does not include withholding CFDI or the SAT's Withholdings service, and the status of each CFDI is not queried one by one at the SAT from the register.
  • The SAT only confirms the format when it receives it: the first DIOT and the first trial balance are reviewed with your accountant, and stamping is tested first in the PAC's test environment.
Frequently asked questions

What we are usually asked

Do I need to hire a PAC?

Yes. The SAT does not offer an API to stamp in bulk on your own: stamping is done by a CFDI Certification Provider (PAC). The platform generates and seals the XML with your CSD and the PAC only stamps it. FacturoPorTi and SW Sapien come built in and are interchangeable; you start in the PAC's test environment and move to production when everything works.

Does it file my tax returns, the DIOT and the electronic accounting with the SAT?

No. The SAT has no API for those filings. The platform calculates the working paper, generates the DIOT file and the electronic accounting XML files, and records what a person filed, with its operation number or acknowledgment, so you can later compare whether anything has changed.

What happens with my e.firma and my CSD?

They are validated on upload and stored encrypted. The e.firma is kept in an AES-256-GCM envelope in a folder outside the web root; nothing encrypted sits in the database. Neither is ever shown or downloadable again, and neither is exposed through the API or Bastino.

Which tax regimes does it calculate?

The working paper calculates provisional payments for RIF (621), RESICO individuals (626) and individuals with business and professional activity (612), including VAT. The catalog includes all 19 SAT regimes and is open to adding more calculations. Calculators for legal entities, the annual return and INPC inflation adjustment are not available yet.

Does it work for an accounting firm with several clients?

Yes. You can manage several taxpayers, individuals and legal entities, in the same installation, each with its own regime history, e.firma, CFDI register and periods. Permissions separate who can view, request from the SAT, classify, close periods or submit accounting.

Are they sold separately?

They are installable Fisher Platform modules: you activate or deactivate them separately and, when deactivated, their screens disappear. They work together, but each can be used without the other. Contact us and we will tell you what your plan includes.

See it with your company's CFDI

We activate the module, load your issuer and your CSD in testing, and walk through how an invoice is stamped, how SAT data is downloaded and how the working paper is built.

Fisher Networks ventas@fishernetworks.net 442 138 8102
Send an email
About the screenshots and the data

The screenshots come from a demo environment with fictitious taxpayers, customers, invoices and CFDI. The RFCs are made up: they have the shape of an RFC but belong to no one. No communication took place with the SAT or any PAC: stamped documents are in the test environment with a simulated PAC, and the e.firma and CSD are test certificates generated for the occasion. Calculations are shown with that sample data and do not replace your accountant's review; SAT rules change over time.

View plans