Can it sit on top of the system I already have?

Almost always. If it exposes its data, the invoicing layer is built on top; if it does not, the interface gets built first. Replacing it is the last option, not the first.

What about credit notes and cancellations?

They go through the same flow, linked to the original invoice, because a loose cancellation is the one you cannot explain later.

And payment complements?

They are designed in from the start when you sell on credit. It is the part most often forgotten and the one that draws the most observations.

Does this make us dependent on you?

No. The repositories and the infrastructure end up in your name, with technical documentation and a database backup. If one day you want us out, you can.

Invoicing with CFDI 4.0 from your own system

The invoice comes out of the place where the catalogue, the customer and the quote already live, instead of being retyped into a separate portal.

Tell us about your case

The problem

You quote in one system, sell in another and invoice in a third party’s portal. The same data gets typed three times, and one mismatch is enough for the customer to reject the invoice or the tax authority to flag it. When a review comes, reconstructing what was invoiced against what was delivered takes days.

How you notice it

Someone copies the tax ID and the CFDI use from an email into a portal.
The approved quote and the issued invoice live in two places nobody reconciles.
When a customer asks for a re-invoice, somebody has to find what happened to the original.
Nobody knows this month’s invoiced total without opening the provider’s portal.

Use cases

What we build

From quote to invoice without retyping. What was approved is what gets invoiced. The catalogue, the price that applies to that customer and their tax details are already in the system.
The tax authority catalogues inside. Product key, unit, payment form and method, CFDI use and tax regime, as system lists and not as something someone remembers.
With the stamping provider you already use. Stamping connects to the provider you already have. We do not switch your provider to sell you ours.
Customer tax details, entered once. Tax ID, legal name, regime and CFDI use live with the customer, along with their fiscal address, and apply themselves when invoicing.
Several companies, separate data. If you invoice from more than one legal entity, each one sees its own, with the separation built into the design.

What we have written about this

Where we have done this

Sales management · Invoicing

Quote and invoice in the same place

A management system for small companies where the catalogue, the customers and the quotes live together, and the invoice comes out of the same place with CFDI 4.0, the Mexican electronic invoice. Each company only sees its own: the separation is in the design, not in a permission someone has to remember to set.

Scope: Customers, catalogue, quotes
Tax: CFDI 4.0
Status: Online

See the whole case

Use cases

What people ask us

Can it sit on top of the system I already have?: Almost always. If it exposes its data, the invoicing layer is built on top; if it does not, the interface gets built first. Replacing it is the last option, not the first.
What about credit notes and cancellations?: They go through the same flow, linked to the original invoice, because a loose cancellation is the one you cannot explain later.
And payment complements?: They are designed in from the start when you sell on credit. It is the part most often forgotten and the one that draws the most observations.
Does this make us dependent on you?: No. The repositories and the infrastructure end up in your name, with technical documentation and a database backup. If one day you want us out, you can.

45 minutes to find out whether this applies to you

Four questions first, so the call starts where it matters instead of at the beginning. If in those 45 minutes we see this is not for you, we say so right there.

Tell us about your case