Payment gateways and ZATCA-compliant e-invoicing platforms for Saudi enterprises.
This is the one technology category in Saudi Arabia where a regulator can fail you for getting it wrong, and where a customer can walk away for the same reason. An invoice that ZATCA will not clear is not an accounting inconvenience - it is a sale you cannot complete. A payment you cannot reconcile to the invoice that caused it is not a finance problem either; it is a hole in the record both your auditor and your tax authority are entitled to look into. Payments and e-invoicing sit in one category on this site because they are the two ends of the same commercial event, and because organizations that buy them separately spend the following year joining them up.
Most organizations that come to us have already "done" e-invoicing once. They generated compliant invoices, passed the first phase, and discovered that the second phase is a different project with a different shape: the first asks what your invoice looks like, the second asks whether your systems can hold a live conversation with a government platform, every day, including the days they cannot. That gap - between a formatting exercise and an integration obligation - is what this page is actually about.
Our interest, stated before the argument rather than after it. Trustangle is an independent advisory firm. We do deliver selection and implementation work, and that is a genuine commercial interest in your decision - you should have it before you read further rather than discover it on a partners page afterwards. Where we hold a partnership or an accreditation with a vendor named on this page, it is published on our partners page rather than implied in the copy, and it does not decide our recommendation. What we do not do is earn a margin on your licence, which is what makes it possible for us to tell you that the compliance module already bundled with the system you own may be the correct answer, and that the shortlist you were about to run does not need to exist.
This is a category rather than a product, and being precise about what sits inside it is worth the two minutes - because most of the expensive mistakes here come from buying one layer and expecting the behaviour of another. There are five, in the order a single transaction passes through them.
The system the invoice is born in. Your ERP, your accounting package, your point of sale, your billing or subscription engine - whatever actually creates the commercial document. This layer is usually not for sale in this category, and it is usually the layer that decides how hard the rest will be. An organization whose invoices originate in three different systems has three integration problems, not one, and no compliance product removes that.
The e-invoicing layer. The component that turns that document into a compliant electronic invoice and carries it to the tax authority: the required structured format, the unique identifier, the hash chain that links each invoice to the one before it, the cryptographic stamp, the QR code, and the conversation with ZATCA's Fatoora platform. Two behaviours live here and they are not the same: standard invoices between businesses are cleared - the authority sees them before your customer does - while simplified invoices to consumers are reported after issue. A shop floor cannot wait for clearance and a B2B invoice cannot skip it, which is why a business doing both needs a solution that does both properly rather than one well.
The payment layer. Acceptance and collection: cards and the national scheme, wallets and bank transfer, links and hosted checkouts, terminals in branches, recurring and instalment collection, and the relationship with whoever is licensed to move the money. The decision here is rarely about which checkout looks better. It is about which methods your customers actually use, what each costs you per transaction, when you get the money, and what happens when a payment succeeds and the order does not.
Reconciliation. The layer nobody demonstrates and everybody discovers: matching a cleared invoice to a settled payment to a ledger entry, across the fees, refunds, chargebacks, partial captures, credit notes and timing differences that make those three numbers legitimately disagree. This is where the finance team's month actually goes. If a shortlist has not asked about it, the shortlist is not finished.
Archiving and evidence. Keeping the compliant invoice, in its compliant form, for as long as the law requires, and being able to produce a specific one - with its stamp and its clearance response intact - when someone asks. A PDF in a shared drive is not this. The question that settles it is simple: if an inspector asks for one invoice from three years ago, how many people and how many days does producing it take?
Three things make this category matter now in this market specifically. The e-invoicing regime has moved from a documentation exercise to a live integration obligation, which turns a finance project into an IT one. Payment behaviour in the Kingdom has moved decisively to digital and to instant expectations, so the gap between taking an order and being paid is now a commercial disadvantage rather than a back-office detail. And the two are converging: the same transaction now has to satisfy a tax authority and a payments regulator at the same moment, and the organizations that handle that well are the ones that stopped treating them as separate purchases.
The signals below reliably precede a good outcome here. You do not need all of them; two or three together usually mean the investment will repay itself.
You passed the first phase with a bolt-on. Something was added beside your accounting system to produce a compliant-looking invoice, and it was the right decision at the time. The integration phase asks that thing to hold a reliable, authenticated, continuous conversation with a government platform - which is a different engineering problem, and one most bolt-ons were never built for.
Invoices are born in more than one place. The ERP issues some, the point of sale issues others, a billing spreadsheet or a project system issues the awkward ones. Each needs its own path to compliance, and the numbering, the hash chain and the reporting have to stay coherent across all of them.
You are more than one legal entity, or more than one branch. Multiple commercial registrations, a VAT group, cross-entity recharges, branches issuing in their own name - every one of these multiplies the registration, device onboarding and numbering work, and every one of them is a place where a generic implementation quietly gets it wrong.
Rejections are handled by a person, not a process. When the authority refuses an invoice, someone notices, tells someone else, and it gets fixed by hand. That is survivable at low volume and it is the first thing to break when volume rises - and by construction, nobody finds out until the month is closed.
Settlement does not reconcile without manual work. What the payment provider deposits, what the invoices say, and what the ledger shows need a spreadsheet and a careful person to agree - every week, forever.
You take money in ways the invoice system does not know about. Transfers against a proforma, collections taken in the field, links sent over a messaging app, cash at a branch. Each is a legitimate way to be paid and each is a place where the document and the money separate.
When you do not need this yet. If you are a single entity, issuing from one modern system whose vendor already ships and maintains a compliant integration, at a volume your finance team handles comfortably, then the correct answer may well be to configure and test what you already own - and the honest version of that advice is that a selection exercise would be a way of spending money to arrive back where you started. The same is true if your real problem is that nobody has agreed who owns a rejected invoice or how a credit note gets approved: a platform will industrialise the disagreement rather than resolve it. That is not a reason to do nothing. It is a reason to spend a few weeks on process and ownership first, after which the software decision becomes both cheaper and much easier to make. We say this often enough to have put it on the page.
Every evaluation we run starts from your operation rather than from a feature grid, for a practical reason: the serious solutions in this category all claim the same headline - compliance - and a comparison built on headline claims will therefore always produce a tie. Compliance is table stakes and the wrong question. The useful questions are how a solution behaves at the edges of your business, and what it costs you to keep it compliant after the rules change again.
Seven, weighted differently for every organization, and deliberately not scored out of ten - a score hides the trade-off that is the actual decision.
Where compliance sits architecturally. Embedded in the system that issues the invoice, a middleware layer between your systems and the authority, or a service you send documents to. Each is defensible and they fail differently. Embedded is simplest until you have a second issuing system; middleware handles many sources at the cost of a component to own; a service is fastest to start and hands the most control to someone else.
Coverage of both invoice behaviours. Whether clearance and reporting are both first-class, or one is an afterthought - and specifically what the point of sale does when the connection to the authority is unavailable mid-queue.
Failure handling. What happens to a rejected invoice: who is told, how fast, whether it retries, whether the queue is visible to a human, and whether a backlog can be worked through without a developer. This is the single strongest predictor of how the system will feel to live with, and the single least demonstrated.
The integration surface. What it takes to connect your issuing systems - documented interfaces or a bespoke bridge, who maintains that bridge when either end upgrades, and whether your ERP's own roadmap is about to make the question moot.
Key custody and data residency. The cryptographic material that stamps your invoices is, in effect, your signature. Who generates it, where it is stored, who can use it, what happens if the vendor relationship ends, and where the invoice data itself lives. This is a governance question wearing a technical costume, and it should be answered by your risk people as well as your IT people.
Payment scope and neutrality. Which methods are supported for the customers you actually have, what the per-transaction economics are once every fee is counted, when funds settle, and - importantly - whether the solution ties you to one licensed provider or lets you change your mind later without changing your checkout.
Reconciliation and archive. Whether invoices, clearance responses, settlements and ledger entries can be tied together without human assembly, and whether a single historical invoice can be produced intact on demand.
We ask these before looking at any vendor, because the answers usually shorten the list faster than any demonstration does - and occasionally they end the exercise, which is a legitimate result.
Which systems issue invoices today, and is that list going to be the same in two years? How many legal entities, branches and registrations are involved, and does any of them invoice in its own name? What is your split between business customers and consumers, and where does each transaction physically happen? What did you implement for the first phase, who maintains it, and is anyone still under contract to? How are you paid today - every method, including the inconvenient ones - and which of those never reaches the invoicing system cleanly? Who in your organization is accountable when an invoice is rejected, and what do they do about it today? What is your position on where invoice data and cryptographic keys may reside? And the question that reframes the exercise more often than any other: what is the cost to you, in real terms, of an invoice that cannot be issued for one hour on your busiest day?
The output is a shortlist with the reasoning attached - including the option of keeping what you have - and a normalised view of the quotations, which vendors do not write to be comparable. If you want that method applied to your own estate rather than read about, Get an impartial assessment.
We work across this category at every layer described in section 1, rather than resell one position in it. In practice an engagement lands in one of five places, and the first question is always which of them your problem actually is.
Making the system you already own compliant. The most common good outcome and the least commercially interesting one: a modern ERP or point of sale whose compliance capability is present, unconfigured and untested. The work is configuration, registration, onboarding and proving it under load, not procurement.
A dedicated e-invoicing layer. For estates with several issuing systems, entity complexity, or an issuing system whose vendor will not carry the integration. This is where a specialist component earns its place - one path to the authority, one place to watch the queue, one team to call.
The payment layer. Acceptance, checkout, terminals, links and recurring collection, chosen on your customers' actual methods and on total per-transaction cost rather than on headline rate - and specified so that the provider can be changed later without rebuilding the experience.
The join between them. Invoice-to-payment-to-ledger, which is the layer most often left to a spreadsheet and the one that most reliably repays being built properly.
Two products of our own sit in this category - ReachPay and Reachware Fatoora. We have deliberately not summarised either in a line here: a one-sentence characterisation of a platform is the kind of claim that is both hard to verify and quick to age, and their own pages are maintained by the people who build them. Follow the links for what each actually does. Two things are worth saying plainly in their place. The first is that we own products in this category, which is a commercial interest of exactly the kind section 3 exists to hold at arm's length, and you should weigh a recommendation of our own product accordingly and ask us directly what else was considered. The second is a naming point that confuses almost every first conversation: "Reachware Fatoora" is a product name, while ZATCA's Fatoora platform is the tax authority's own government portal that every taxpayer integrates with. They are not the same thing, nobody sells the second, and no vendor - us included - can offer you an alternative to it.
The table compares the five layers rather than scoring the products against each other. That is deliberate: a feature grid of platform names would be a claim about vendor capability at a point in time, which is exactly what FAQ 8.3 says this page will not publish, and it would be out of date before the next release. Layers do not move.
| Layer | What it decides | Reach for it when |
|---|---|---|
| Issuing system | Where the invoice is created, and therefore how many integrations you own | You are replacing or upgrading the ERP or point of sale anyway - decide compliance here first, not afterwards |
| E-invoicing layer | Format, identifiers, stamping, clearance and reporting, and what happens when the authority says no | You issue from more than one system, have entity or branch complexity, or your first-phase solution cannot carry the integration phase |
| Payment layer | Which methods you accept, what each costs, when you are paid, and how a failed payment is recovered | Your customers pay in ways you cannot accept cleanly, or your per-transaction economics have never been calculated end to end |
| Reconciliation | Whether invoice, settlement and ledger agree without a person assembling them | Month-end depends on a spreadsheet and the one person who understands it |
| Archive and evidence | Whether a specific compliant invoice can be produced intact, years later, on request | You cannot currently answer how long producing one would take, which is most organizations |
We publish no price range for this category, and the reason is not coyness. A range wide enough to be true of every organization would be useless to yours, and a narrower one would be a guess presented as a benchmark - which is worse than nothing, because it becomes the number you carry into a negotiation. A buyer evaluating advisers should discount such figures wherever they appear, this page included. What follows is the structure of the cost, which is portable: you can apply it to the quotation actually in front of you tonight.
The licence or subscription is usually the smallest line and the one every comparison fixates on. Read what meters it - documents, transactions, entities, users, devices or issuing systems - because the meter, not the rate, is what decides what you pay in year three. A price per document is a very different commitment for a retailer than for a contractor.
Integration is the line that varies most and the one most often quoted from an assumption. It scales with how many systems issue invoices, how modern their interfaces are, how much your processes deviate from the standard shape, and whether anyone can still explain the customisations made to your ERP years ago.
Per-transaction payment costs are a running cost, not a project cost, and at volume they will exceed everything else on this list combined. Count all of it: the scheme and provider fees per method, refund and chargeback handling, settlement timing and any cost of the money you are waiting for, and what it costs to move providers later.
Your own people are a real cost and are almost never in the quotation. Finance for testing and validation, IT for the integration and the identity work, and the time of whoever knows why your invoices are the shape they are - who is usually one person and usually already busy.
Regulatory change is a cost with no end date. The rules in this area have changed before and will change again. Ask, in writing, who absorbs the cost of the next change: if updates are included, what counts as an update, and what has to be true for a change to be billable instead.
Exit is the line nobody prices at the start and everybody meets eventually. What it takes to get your archive out in a usable form, what happens to your cryptographic material, and whether your checkout or your invoice numbering is coupled to a vendor you may want to leave.
The three-year view assembled from those six is the number worth comparing, and it is the one we build with clients. Quotations that look alike at the licence line routinely differ several-fold once integration, transaction economics and change are counted.
Deliberately structural. This page names no article, control number, wave, revenue threshold or date, because those are precisely the values that go stale inside a web page while continuing to look authoritative - and a reader who acts on a stale threshold is harmed by it. Verify the current position against the authorities' own published material, or ask us and we will check it with you against the source.
The e-invoicing regime has two phases and they ask different things. The first concerns generation: invoices must be issued electronically in a compliant structured form, with the required content, and paper or free-form documents no longer satisfy the obligation. The second concerns integration: your systems connect to ZATCA's Fatoora platform and exchange invoices with it, carrying the required identifiers, hashing, cryptographic stamping and QR code. Organizations were brought into the second phase in groups over time rather than all at once. Which group you are in, and when, is a fact about your business that should be confirmed against ZATCA's current published criteria rather than inferred from a vendor's slide.
Clearance and reporting are different obligations. Standard tax invoices - broadly, business to business - are submitted to the authority and cleared before they are shared with the customer. Simplified invoices - broadly, business to consumer at the point of sale - are issued to the customer immediately and reported to the authority afterwards. Any business doing both must handle both, and the operational implications are opposite: one tolerates a round trip, the other cannot.
Invoice content and language. Required fields, the tax treatment shown correctly, Arabic content where the rules require it, and dating conventions handled so that Hijri and Gregorian references cannot drift apart. These sound like formatting details until an invoice is refused for one of them.
Payments are regulated separately, by the central bank. Moving money on behalf of others is a licensed activity in the Kingdom, the national card scheme and the national payment infrastructure sit underneath most of what a customer experiences, and card acceptance carries its own international security obligations. Two practical consequences for a buyer: confirm that whoever holds the money relationship is licensed to do so, and confirm where the card-security obligation falls between you and your provider, because that answer changes with how your checkout is built.
Personal data. Invoices and payment records are personal data when they identify individuals, and the Kingdom's personal-data regime and its supervising authority govern how they may be processed, transferred and retained. This bears directly on a hosting decision that is often made on cost alone.
Cloud and cybersecurity controls. Where the national cloud cybersecurity framework applies to your organization, it shapes where this system may run, how it is segregated and what evidence of control you are expected to hold. Establish that before a shortlist rather than after one, because it removes options rather than ranking them.
Retention and evidence. Compliant invoices must be kept, in a form that remains verifiable, for the period the law requires. The test that matters is not whether they are stored but whether a specific one can be produced intact when asked for.
Five stages. The first two are where the decision is actually made; the rest is execution discipline.
Establish the obligation and the estate. Which entities and registrations exist, which systems issue invoices, what split of clearance and reporting you have, what was built for the first phase and who maintains it, and how you are paid today. This is a fact-finding stage and it regularly changes the question the organization thought it was asking.
Decide the architecture before the vendor. Embedded, middleware or service; one path to the authority or several; where keys and data will live. Choosing a vendor before this is choosing an architecture by accident, and it is the most common way this category goes wrong.
Shortlist and test against your own invoices. Not a demonstration - your documents, including the ones that embarrass you: the credit note, the multi-entity recharge, the foreign-currency line, the return processed the following month, the invoice your industry has that nobody else does. Vendors show the happy path; your exceptions are where the cost lives.
Implement with the rollback written down first. Registration and device onboarding, integration, validation against the authority's own tooling, a parallel run, and a documented answer to what you do on the day the connection fails during business hours - decided in advance, in writing, and rehearsed.
Hand over so you are not dependent on us. Runbooks for the rejection queue, named ownership inside your organization, the reconciliation process documented, and a plan for the next regulatory change. An adviser who leaves you unable to operate without them has created a commercial relationship, not a capability.
We publish no standard duration, for the same reason we publish no price: the honest answer depends on facts about your estate, and a figure quoted without them would be a marketing number that becomes a commitment in your reader's mind. Here is what actually drives it, which you can apply to any plan a vendor puts in front of you. The number of systems that issue invoices, and whether each has a documented interface or needs a bespoke bridge. The number of entities, registrations and branches to be registered and onboarded. Whether both clearance and reporting are in scope. How far your invoicing practice deviates from the standard shape - industry-specific documents and historical customisations are where plans slip. The state of your master data, which is the single most common cause of an overrun in this category and the one least visible at the planning stage. And your own team's availability, since validation cannot be outsourced: someone who knows your invoices has to confirm they are right. A plan that has not asked about those six is a template, and you should treat its dates as such.
Section 5 sets out the six lines. The two that most often decide the comparison are the ones absent from the licence quotation: per-transaction payment costs, which at volume exceed everything else combined and are rarely modelled honestly at the outset, and regulatory change, where the question "who pays for the next one" has a contractual answer worth establishing before signature rather than discovering afterwards. Add your own people's time and the cost of exit, and quotations that looked equivalent frequently are not. We build this view with clients from their actual volumes; we will not publish a number for someone else's.
Compliance attaches to a deployment, not to a brand. The same product, configured two ways, in two hosting arrangements, for two organizations with different obligations, can be compliant in one case and not in the other - so we do not publish a compliance verdict on any vendor, including our own. What we can tell you is what determines the answer: which phase and obligations apply to your entities; whether the deployment handles both clearance and reporting as your business actually needs; where invoice data and the cryptographic material are stored and who can access them; whether your hosting satisfies the personal-data regime and, where it applies to you, the national cloud cybersecurity framework; and whether the payment side sits behind a properly licensed provider with the card-security obligation clearly allocated. There is one check we would push you to make yourself rather than take from any adviser: ZATCA publishes its own list of solution providers it has qualified. It is public, it is authoritative, and it is current - look up any vendor you are considering on it directly, including anything recommended on this page. An adviser's assurance is not a substitute for the register.
You should ask this of any adviser, and the answer should be uncomfortable in its specificity - which options were considered, which were discarded, and on what evidence. Our recommendations name what was ruled out and why, and they always include the two options a seller has no reason to raise: configuring the compliance capability you already own, and doing nothing this year because the obligation you are preparing for is not yet the one you face. Both are real recommendations we have made. One more thing belongs in this answer specifically on this page: we own products in this category, so if we recommend one of ours, ask us the question above harder - and ask what a client with your profile would have been recommended if we owned nothing.
Usually yes, and in this category "without replacing them" is the normal and preferred outcome rather than a compromise. The whole point of a dedicated e-invoicing layer is to leave the systems that issue invoices where they are. The real questions are how the connection is made, who maintains it when either end upgrades, and how the exceptions behave - because a connection that handles standard invoices and breaks on your industry's awkward document has not actually integrated anything. Two cautions worth stating. An issuing system old enough to lack usable interfaces can make a bridge more expensive to build and keep than the modernisation it was avoiding, and that arithmetic is worth doing explicitly. And where your ERP's own vendor already ships a maintained compliance capability, adding a third-party layer beside it means owning an integration you did not need - which is a decision, not a default.
This section is titled for numbers and contains none, so it should explain itself. We do not publish counts of clients, projects, invoices processed or transactions handled on this site. Not because there is nothing to count, but because a number on a web page is unverifiable by the person reading it, trivially inflated, and impossible to distinguish from an invented one - which makes the whole genre worthless precisely where it claims to be evidence. A reader comparing advisers should apply that scepticism to everyone, this page included.
What is worth more is knowing which numbers to demand, and being able to check them. In a first meeting, ask any adviser in this category - us included - for these, and expect specifics rather than adjectives. How many implementations of this exact shape have the named people on your project actually done, and when? What proportion of their engagements are still supported by them a year later, and can they put you in touch with one? What is their measured rejection rate after go-live on a comparable estate, and what caused the rejections? How many of their clients have been through a regulatory change with them, and what did it cost those clients? And the one that separates advisers from resellers: how many times have they recommended against a purchase?
We answer all of those, with named references, for your specific evaluation and under the confidentiality our clients are owed. Our published record - the engagements clients have approved for publication - is on the success stories page, and it is the honest extent of what we can show a stranger on a web page.
Named clients and logos appear on our customers page, which is maintained with permission. This section describes the shapes of organization we do this work for, which is more useful for deciding whether we are relevant to you than a wall of marks.
Multi-entity groups, where the complexity is registrations, intercompany documents and keeping numbering coherent across companies that share a finance team. Retail and hospitality operators issuing at the point of sale across many branches, where the binding constraint is what happens at the till when the connection is not there. Contractors, project businesses and professional firms, whose invoices are staged, retained, certified or milestone-based and therefore never quite fit a standard template. Wholesale and distribution businesses issuing high volumes of business-to-business documents where clearance latency is an operational question, not a technical one. Subscription and services businesses, where the invoice is generated by a billing engine rather than by a person. And organizations that completed the first phase with something temporary and now need the integration phase done properly - which is, at the time of writing, the most common reason anyone calls us about this category at all.
If your shape is not in that list, it does not mean we cannot help - it means the first conversation should establish whether we are genuinely the right people, and we will tell you if we are not.
Our published project record is on the success stories page. It carries the engagements our clients have approved for publication, with the detail they approved, and it is the honest extent of what we can show a stranger on a web page.
What we will not do is describe an anonymised composite as though it were a project. "A leading Saudi retailer" is a construction that permits any claim at all, because there is no organization who could contradict it, and the reader has no way to tell an anonymised real engagement from an invented one. In a first conversation we will talk in specific detail about work of a shape similar to yours - what the estate looked like, what we recommended, what went wrong, and what we would do differently - within the confidentiality each client is owed.
Approved client feedback appears on our customers and success stories pages. There is no quotation on this page, and its absence is deliberate: we do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, for the specific place it will appear. A testimonial written by a marketing team and attributed to a job title is not evidence of anything, and a reader cannot distinguish one from the real thing - which is precisely why the real thing is worth protecting.
If what you actually want is to hear from someone who has been through this decision, ask for a reference call. It is a better test of an adviser than any quotation, and it is one we are happy to be put to.
Our current vendor relationships, accreditations and the certifications our consultants hold are published on the partners page. We keep them there rather than restating them in category copy for a practical reason: partner tiers and individual certifications change, and a page that asserts a status it can no longer stand behind is worse than one that does not assert it at all. Treat that page as the current answer, and ask us directly about any specific platform you are evaluating.
In this category there is a better check available to you than any page we could write, and we would rather point you at it than be believed. ZATCA maintains and publishes its own list of the e-invoicing solution providers it has qualified. It is public, authoritative and current, and it answers the question that actually matters about any vendor in this market - including ours. Look up every name on your shortlist there directly. If an adviser's description of their standing and the register disagree, the register is right.
Beyond that register, here is what we would check about any implementation partner in this category, us included. Ask for the certification of the named individuals who will be on your project, not the firm's aggregate status, and ask whether those individuals are committed to your dates. Ask for a reference from an engagement of comparable entity complexity and invoice volume, ideally one that went less than smoothly, and ask what was done about it. Ask how the commercial relationship works - whether the partner earns on the licence or on the transactions as well as on the implementation, and what that means for the advice you are getting. Ask what handover looks like and what you could change yourself afterwards. A partner who answers those four without flinching is a much better signal than a badge.
If you are at the start of this, section 1 is the genuinely useful part of this page - the costly mistakes in this category are made by buying one layer and expecting another. If you already have a shortlist, take section 3.1 and section 5 into your next vendor meeting; they are written to be used that way.
From here: All solutions and platforms covers every category we work across, which matters because this decision almost always touches your ERP or your point of sale. Independent software comparisons sets out how we compare platforms and normalise quotations that were not written to be comparable. And Get an impartial assessment applies the method in section 3 to your own estate - which in this category usually means looking at the integration surface before looking at any vendor at all.
The material above is the general shape. Yours has a specific set of entities, a specific mix of business and consumer invoicing, systems of a specific age, and a set of constraints no published page can weight. Tell us three things - which systems issue your invoices, what you put in place for the first phase, and how you are paid - and that is enough for a first conversation and enough for us to tell you whether you need a full evaluation, one layer, or nothing at all this year.
What that conversation will not be is a product pitch. We own two products in this category and we will say so again here rather than let it surprise you later; what we do not do is earn a margin on a third party's licence, and we are willing to tell you that the capability already sitting unconfigured in your ERP is the right answer. Book a decision session and bring the problem you actually have - it is a more productive hour than a demonstration of software neither of us has established you need yet.
