Tax certificates, bank statements, payslips, bills, INE cards, CFDIs and deeds. Each document enters the file already read — and certificates and CFDIs are also confronted with the SAT.
Each type returns its own fields. Certificates and CFDIs are confronted with the SAT and come back with their verdict.
The certificate is read —name or legal name, tax ID, idCIF, CURP, regime, address, activities and obligations— and cross-checked against the SAT record. It returns the verdict and the taxpayer standing.
The opinion outcome (positive or negative), the folio, the taxpayer tax ID and the issue date are captured. The digital seal is verified against the SAT certificate.
Fiscal folio (UUID), issuer and recipient with their tax IDs and the total are read, then used to verify against the SAT whether the invoice was issued and is still valid.
The whole statement is read: bank, holder, account and CLABE, period, balances, deposits and withdrawals, and every movement. The embedded fee CFDI is verified against the SAT and its recipient is cross-checked against the account holder.
Each payslip is captured on its own: employer and employee with their tax IDs and the employer registry, NSS and CURP, earnings, deductions, net pay, the period and the pay date, and the SBC/SDI. The payroll CFDI is verified against the SAT.
From CFE, Telmex, water, property tax and more: the service holder, the full itemized address, the service number, the period, the amount and the issue date. When the bill is a CFDI (CFE, telecom…), it is also verified against the SAT.
From a CEP or SPEI receipt: sender and beneficiary with their accounts, the amount, the tracking key, the authorization and the concept.
Front and back are read: name, CURP, voter key, date of birth, address and section.
The legal name and company form are read, along with the ownership and control structure: shareholders with their percentage, directors, attorneys-in-fact and their powers, the registered address, the capital and corporate purpose, the notarial data and the commercial registry entry. Whoever controls from 25 per cent up is flagged.
It reads who grants the power and to whom, with which faculties and scope, before which notary and under which deed number, and how long it runs.
Singula reads tax certificates, bank statements, payslips, proofs of address, payment receipts, INE cards, CFDIs, incorporation deeds and powers of attorney, as a photo or a PDF. It returns every value exactly as printed and stores the original file in the customer record.
Every document returns a verdict —genuine, suspicious or forged— with the reason behind it, in seconds.
The document’s tax recipient does not match the account holder.
We confirm the document was not manipulated, edited or recreated.
We cross-check the document against the SAT, RENAPO or INE record that applies.
We compare the document holder against what its issuer registered.
The rules of the type arrive already evaluated, next to the data. Each rule comes back as met, not met or not evaluable. A rule that is not evaluable never reads as passed: it means a document is missing or the source has not answered yet.
A bank statement counts as a proof of address and answers the same rules.
Thresholds and rules are configured per organization. The ninety days on a proof of address are the factory value, not a fixed limit.
Your customer uploads it from inside your product, or your team adds it to the file of a customer already on record.
The document type is identified and the printed values are captured, with no sorting beforehand.
A bank statement returns the period and the movements; a utility bill returns the address and the issue date.
The information is stored next to that customer’s other checks, and your system is notified once the reading is done.
The documents you read feed three processes in the customer file.
Use it directly (the value in the body) or on a customer file. Same response.
Leasing, consumer credit and any process that verifies income. Statements and payslips arrive captured, with their period and their amounts.
The bill arrives with the address already captured, along with the service holder and the issue date. It is ready to check against what was declared on the application.
Accounts payable and expense reporting. Each amount arrives captured, with its reference, its date and its line items.
This product captures the values on the documents and stores them in the customer file. The decision on each file stays on your side.
Tax status certificates, compliance opinions, CFDIs, bank statements, payslips, proof-of-address bills, payment receipts (SPEI/CEP) and deeds. A phone photo works, and so does the file the source issues. The certificate and CFDIs (invoices, CFE or telecom bills) also arrive verified against the SAT. The INE voter card has its own page, because that lookup asks the INE for the status of the card.
The tax status certificate and CFDIs (invoices and CFE or telecom bills). The certificate is cross-checked against the SAT registry and comes back with an authenticity verdict plus the taxpayer status. A CFDI is checked against the SAT to tell whether it is still valid or was cancelled. Every other document is read and stored in the file, with no cross-check.
No. Send the file as it comes: the type is identified and the values that document carries are returned. A bank statement and a utility bill do not yield the same thing.
Yes. The test environment answers with mocked data and consumes no balance, so your team can build the whole integration before sending a single real document.
Inside that customer’s file, with their other checks. You create the file once, and every check you add afterwards is stored there with its date.
Start in the free test environment. Every value comes back captured inside the customer file.