Create invoices with lines their system can read
Your product already holds what an invoice is made of: the work done, the quantities, the prices. What it does not hold is the item, the ledger account and the tax rate the customer's system expects the line to reference. Maesn delivers those, then writes the invoice.
- An item from their catalogue6 systems
- or a ledger account, and a tax rate
Across the connected systems, 10 accept an invoice you write. Fewer will tell you what belongs on its lines.
The invoice writes easily, the line is the work
Two counts that people expect to move together, and do not. Writing the document is among the better covered operations in the model. Knowing what belongs on its lines is not.
An invoice line is a small object with a large dependency. The description, the quantity and the price come from your product, and they are the easy part because you already have them. What the line has to point at is somebody else's data: an item from the customer's catalogue or a general ledger account, and a tax rate that exists in their system under their code.
That dependency is the whole difficulty of this use case, and it is why the documented flow spends more steps fetching than writing. It is also why three of those steps are marked optional. Called optional, that sounds like a nicety. Read against the coverage it is something else, because on half the systems that accept an invoice there is simply no item catalogue to fetch. The tax rate has a second complication of its own, since a rate frequently arrives without any statement of how to apply it.
None of this makes the use case fragile. It makes it specific: what you can promise your users depends on which systems they are on, and that is knowable in advance rather than at the first failed posting.
One connection for the catalogue, the accounts and the rates
The reads that make a line valid arrive in one shape from every system, which is what lets your users map their own data onto their own accounting setup instead of you doing it per vendor.
The first documented step is not about invoices at all: the customer has to exist on both sides and mean the same thing, which is its own use case under customer and supplier data sync. It is the least fragile part of the chain, because customer records are the best covered object in the model on both reading and writing.
After that the reads all answer the same question in different words: what may a line refer to. Items, ledger accounts and tax rates arrive through the same normalized objects on every connected system, so the interface where your users pick a default item or map a service to an account is built once. Where a system holds something the shared model has no field for, reaching past the model is documented, and the customer authorises all of it once through one authentication flow.
What Maesn does not do is invent the reference. If a system exposes no item catalogue, no layer can produce one, and a line there carries your description and a ledger account. Two systems can both accept an invoice and still disagree about what a line is allowed to say, which is the kind of difference an integration layer can normalize the shape of but not the substance.
Your trigger, their invoice, no re-entry
The end of the flow is deliberately small. Once the references are known, creating the invoice is a single call, and the interesting decision left is when to make it.
All three reads are optional in the guide, because not every system offers all three.
- A real invoice, not an export
- Lines that reference their data
- Booked where their accountant looks
- No second entry by hand
The trigger is yours by design. The guide offers a button in your interface, a reaction to an event, or a scheduled run, and it does not prefer one, because the right answer depends on a workflow your users already have rather than on anything about the connection. A product that transfers invoices nightly and one that transfers them the moment a job is signed off are the same integration with a different decision in front of it.
What arrives is a real document in their system rather than a file somebody imports. If instead you already hold the finished invoice as a PDF, the guide sends you elsewhere in one sentence, and that boundary is worth respecting: uploading a produced document and assembling one from structured data are different jobs. Where the invoice is one step in a longer receivable, including the payment against it, accounts receivable is the page that covers the rest, and once a system emits events, webhooks tell you when something changed on their side.
Tracked work, invoiced in their customers' systems
Clockin turns tracked work into invoices in their customers' systems.
“We use Maesn to successfully leverage integrations and partnerships as a key driver for lead generation and expansion into new markets and customer segments. By connecting Clockin to our customers' accounting systems, project data flows directly into their existing tools, ensuring a smooth, reliable data exchange with the systems they already use.”
Clockin is this use case in its plainest form: time and project data captured in one product, and an invoice that has to appear in whichever accounting system the customer already uses. The quote names the mechanism rather than the outcome, which is the useful part, since the data flowing directly into the existing tools is exactly what removes the re-entry step this page is about. Systems like Lexware Office and Xero both accept a written invoice, and they differ on whether a line can point at a catalogue item, which is the distinction the section above is about.
Invoice creation coverage, object by object
The write first, then everything a line has to reference, counted from the per-system documentation.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Invoices, writing | 10 | 17 | 2 |
| Customer records, reading | 20 | 2 | 7 |
| Chart of accounts, reading | 19 | 8 | 2 |
| Tax rates, reading | 12 | 14 | 3 |
| Items, reading | 6 | 20 | 3 |
| Invoice lines, reading | 6 | 17 | 5 |
| Units of measure, reading | 1 | 15 | 13 |
The table is the answer to the only question that really decides feasibility here, which is not whether invoice creation works but how specific a line can be on the systems your own customers run. The top two rows are strong and the rest narrows as it gets more detailed, which is the normal shape of an integration surface rather than a shortcoming.
One row deserves the emphasis it does not get by being small. A unit of measure is exposed by a single system, so a product whose invoices depend on hours, kilograms or square metres reaching the ledger as a unit rather than as part of a description should treat that as a per-system question. Reading only what changed since the last run works here as it does on every other list endpoint, which matters for catalogues that customers edit while your product is running.
We deliver the references, you assemble the invoice
On this use case the boundary sits inside a single object, which makes it unusually easy to state: the line is yours, what it points at is theirs, and the connection carries the second one to you.
- The customer, both directions
- Items, accounts and tax rates
- One shape on every system
- The invoice, written back
- What each line actually says
- Which item or account it uses
- When the transfer happens
- What your invoice looks like
Everything on the left is the connection: the same objects under the same names whichever system the customer runs, and a write that lands as a document rather than as an import. That is the part which would otherwise be one integration per accounting platform, each with its own idea of what an item is.
Everything on the right is your product, and on this use case it is the substance of the invoice itself. What a line says, which item or account it maps to, when the transfer happens and what the finished document looks like to your user are your decisions, informed by the way your customers already work. A layer that made them would be writing your invoices for you.
One thing belongs here because the page it replaces put it somewhere else. This use case does not make an invoice compliant with an electronic invoicing regime, and nothing on this page claims it does. The invoice is created in the customer's accounting system, which is where their local rules already apply, and questions about electronic invoicing networks are worth asking us directly. The lastModified filter on the read endpoints is what keeps the catalogues you cache from going stale in the meantime.
An invoice that lands correctly the first time is what stops being corrected by hand by financial teams.
Common questions
What does it take to create an invoice in a customer's accounting system?
Why are three of the documented steps marked optional?
What actually goes on an invoice line?
Can we send a PDF invoice instead?
Do you handle e-invoicing formats or PEPPOL?
How do we decide when an invoice is transferred?
Does the customer need to exist in the accounting system first?
Which systems can we write invoices to?
What if a system needs a field the shared model does not carry?
Does Maesn decide the tax treatment on the invoice?
Build once on the Unified API.
See how invoice creation works for your integration, or dive into the technical reference.