Medical fees paid in 24 hours. The platform that makes it possible.
Gestical sits between independent physicians and insurance companies in Mexico. Once an insurer authorises a procedure, Gestical pays the physician’s fees within 24 hours, then runs the claim, the CFDI 4.0 invoicing and the collection against the insurer on the doctor’s behalf. That promise only holds if every claim’s stage, documents, invoice and payment order live in one system. Creator Scripts built that system on Zoho Creator and has evolved it continuously since 2015.
Why a 24-hour promise does not scale by hand
Seven conditions the platform had to satisfy. Each is a reason the build is custom rather than configured.
- 1
Physician cash flow is the product
Physicians routinely wait weeks or months for insurers to pay. Advancing fees in 24 hours means Gestical carries the exposure, so the status of every claim has to be airtight or the company absorbs the risk.
- 2
A multi-insurer, multi-stage pipeline
Each claim moves through up to 17 operational stages, from feasibility verification to archived file, across many insurers with their own rules, formats and response times.
- 3
CFDI 4.0 fiscal complexity
Mexican electronic invoicing needs per-insurer, per-state and per-tax-regime logic: state taxes embedded in the Complemento de Impuestos Locales node, retention rates that differ by régimen, and insurers that mandate fixed payment methods and forms.
- 4
Invoice folio integrity
Concurrent invoice generation risks duplicate folios, which is a compliance and reconciliation problem, not a cosmetic one.
- 5
Bank dispersals need a trace
Fees, commissions and refunds go out through separate accounts per concept. Every bank movement has to tie back to the operational record that caused it.
- 6
Stakeholders need their own view
Physicians, partner companies and agents need self-service visibility of their claims, documents and payments, or every status question lands on staff.
- 7
Licensing economics
Managing internal tasks in Zoho CRM would have meant a per-user licence for the whole operations team. Task management had to live inside Creator.
One claim, one record, up to 17 stages
Every claim is a record whose stage drives the workflow. A stage change triggers notifications, task creation and financial events. Nine claim types share the pipeline with per-type behaviour.
- Feasibility verification
- Document review
- Invoice request
- Submission to the insurer
- Approval
- Tariff validation
- Fee paymentwithin 24 hours
- CFDI invoicing
- Collection
- Supplier payment
- Archived file
Exception paths branch off the main line: rejection, conversion to reimbursement, temporarily out, uncollectible. Each is a stage of its own with its own notifications, so nothing leaves the pipeline without a record of why.
The fiscal engine: CFDI 4.0 in Deluge
Invoice generation is fully automated. The engine assembles the CFDI 4.0 payload, submits it to a certified PAC for stamping, and stores the stamped XML and PDF against the claim.
Receptor from the registry
Fiscal data for the invoice comes from the physician’s registered fiscal address, so the payload is right before it reaches the PAC.
Per-insurer payment rules
Método de pago and forma de pago are resolved per insurer, including the ones that mandate PUE with a fixed forma.
State taxes as a complement
ISR and IVA retentions follow the tax regime; state taxes are emitted as a Complemento de Impuestos Locales node rather than as standard retentions.
Atomic folios
A single-record counter issues folios atomically, so concurrent generation cannot produce a duplicate. Stamping errors are captured to a dedicated report for follow-up, and payment complements are generated for PPD collections.
Commission engine
Commission and retention percentages are resolved at data-entry time from four inputs: the insurer, the physician’s state, the operating mode (local or foráneo) and the SAT tax regime. The rules that used to live in people’s heads, such as a 2% versus 5% rate for one insurer in one state depending on régimen 626, are encoded once and applied the same way every time.
Why it matters
CFDI 4.0 rules (state-tax complements, per-regime retentions, per-insurer payment methods) are encoded once and applied uniformly across every invoice, which is what keeps SAT rejection and rework risk down at volume. See how we handle Zoho Books and CFDI for other clients.
Payments on SPEI rails, signed outside the low-code layer
Approved payouts become SPEI orders against Gestical’s STP Mexico contracts, with a dedicated CLABE account per concept, so commissions and refunds never share a ledger line.
Payout approved
A stage change on the claim creates the payment event for the fee, commission or refund.
SPEI order built
Creator assembles the order against the STP contract and the concept’s CLABE account.
Order signed
A dedicated microservice on Google Cloud signs the order with RSA. Private-key material never enters the low-code layer.
Dispersed by STP
The order goes out on the SPEI network to the physician, partner or insurer account.
Callbacks logged
STP movement and state-change callbacks are written back to the platform for reconciliation against the operational record.
What was built, module by module
Delivery has been phased and iterative. Every module below is live in production.
- Claims pipelineCore module tracking every claim through the lifecycle, from feasibility verification to archived file, with per-type behaviour for nine claim types.
- Registration and compliancePhysician, company and insured-patient registries with document-compliance tracking (incorporation, privacy notice, liability insurance, transfer formats) and automated missing-document reports.
- CFDI 4.0 invoicing engineDeluge functions that assemble, stamp and store CFDI 4.0 invoices through a certified PAC, with a shared folio counter guaranteeing unique consecutive folios.
- Commission calculatorOn-input engine applying insurer-, state- and regime-specific commission and retention rules.
- STP Mexico paymentsSPEI dispersal integration for production contracts, dedicated accounts per concept, payment-order signing through a cloud microservice.
- Zoho CRM syncTwo-way link between CRM leads and contacts and Creator physician records, maintained across lead-to-contact conversion.
- Stakeholder portalRole-based portal with dedicated reports and flows for physicians, companies, insured patients and agents.
- Notification systemBranded HTML email framework with a colour-coded accent per event type (finder’s fee, commission, refund, payment complement, invoice request) for internal teams and external stakeholders.
- Native task moduleTask management inside Creator with user detection, portal- and Zoho-aware URLs, scheduled reminders and a dashboard. No per-user CRM licensing for the operations team.
- Executive reportingDashboards and pivots for billing by month, collections, top physicians and companies, inactive customers, receivable ageing (30, 45, 60, 90 days) and duplicate-claim detection.
One Creator application runs the whole operation
Sales handoff from CRM, claims, fiscal compliance, banking, communications and internal tasks, on a single application. The counts describe the production build.
- 125FormsClaims, registries, fiscal configuration, payments, tasks
- 200Reports, aboutOperational views, portal views, executive pivots
- 138Pages and dashboardsInternal surfaces, portal pages, executive reporting
- 1,400Deluge functions and scheduled workflows, aboutPipeline, fiscal engine, commissions, payments, CRM sync, notifications
- 9Claim typesPhysician and company variants sharing one pipeline
- 17Pipeline stagesMain path plus exception paths
Stakeholder surfaces
Role-scoped portal for physicians, companies, insured patients and agents. Branded notifications for every operational and financial event.
Operations
Claims pipeline, registries and compliance, native tasks, executive dashboards and receivable ageing.
Engines
CFDI 4.0 fiscal engine with atomic folios. Commission engine resolved at data entry.
Integrations
Zoho CRM two-way sync, certified PAC stamping, STP Mexico SPEI dispersals with cloud-signed orders, document repository links.
Data
Claims, physicians, organisations, insured patients, documents, invoices, payment orders and bank movements, in one record set.
Integrations around the system of record
Banking, tax stamping and CRM are reached from Deluge inside Creator. The one piece that lives outside is the signing service, and that is by design: private keys do not belong in a low-code layer.
Zoho platform
- Zoho CRMBidirectional physician lifecycle sync. Lead capture pushes records into Creator, updates flow both ways, and lead-to-contact conversion re-links the Creator record to the new contact.Bi-directional
- Creator portalPhysicians track claims, documents and fee payments; companies and agents track their own pipelines.Stakeholders
- Zoho MailEvery notification closes from the operations and management mailboxes.Outbound
Zoho Creator
Operational system of record. Pipeline, registries, engines, tasks, reporting.
9 claim types · 17 stages · one application
External systems
- Certified PAC (CFDI 4.0)Stamping, PDF and XML retrieval, cancellation. State taxes ride in the Complemento de Impuestos Locales node.Bi-directional
- STP Mexico (SPEI)Production dispersal rails for fees, commissions and refunds, with per-concept CLABE accounts and movement and state-change logging.Bi-directional
- Signing microserviceCustom service on Google Cloud that RSA-signs STP payment orders, keeping private-key material out of the low-code layer.Outbound
- Document repositoryLinks to the claim files handled by operations.Reference
What the platform changed
Stated as capability: what the organisation is able to do because claim state, fiscal documents and payment rails are unified.
Physicians affiliated with Gestical receive their fees within 24 hours of insurer authorisation instead of waiting out the insurer’s payment cycle. It is the company’s core differentiator, and it is only viable because every claim’s stage, documents, invoice and payment order live in one system. Cash-flow transformation for customers
Compliance at scale
CFDI 4.0 rules are encoded once and applied uniformly to every invoice, with folios issued consecutively and without a duplicate since the shared counter was introduced.
Operational leverage
Stage changes drive automated emails, tasks, document checks and payment orders, so a small operations team administers the full physician base, the counterparties and the monthly claim volume without added headcount.
Financial control
Receivable ageing at 30, 45, 60 and 90 days, duplicate-claim detection and per-concept bank accounts give management daily visibility of the exposure created by the advance-payment model.
Licence-cost avoidance
Native Creator task management and portal access replace what would otherwise be per-user CRM licensing for operations staff and external stakeholders.
By the numbers, from the production application (July 2026)
- 40,282CFDI invoice folios issued through the fiscal engine, consecutive and duplicate-free
- 1,100+physicians registered and managed on the platform
- ~470organisations administered: insurers, hospitals and partner companies
- ~1,000new claims per month, processed end to end
Claims, invoicing and payouts on one system?
A stage-driven pipeline, a CFDI 4.0 engine with atomic folios, SPEI dispersals signed outside the low-code layer and a role-scoped portal are portable to any Mexican operation that pays or collects on behalf of others.