When a bill checks out, send it straight to your system. When it doesn't, it waits for you — and the moment you've fixed it, it carries on by itself. You set this up once, in plain language, and then stop thinking about it.
Every rule you set up reads the same way: when this happens, only if it looks like that, then do this. If you can say it out loud, you can set it up.
Set up as many of these as you like. They don't interfere with each other.
You fill in a short form. Pick when it should run, add any conditions, then list what should happen — in the order you want it to happen. Move a step up or down with a button.
It won't let you save something broken, either. Leave a step half-finished and it says so on the spot, in words — “this step is missing where to send it” — rather than letting you find out at two in the morning when a bill quietly went nowhere.
The same two things that can happen to any document here. Pick one, or both — one rule can happily handle both paths.
Everything checked out and nobody needed to look at it. This is the one you'll use most — it's the whole point. The document is ready the moment it's read, so whatever you asked for happens straight away.
Something didn't add up, or there wasn't enough on the page to check it against. You might want a copy filed anyway, or you might want the rule to sit and wait for you to sort it out first. Both are fine.
Nothing runs on a timer, and nothing goes hunting for work. A rule only ever moves because a document actually reached one of these two points — so there's no schedule to get wrong, and nothing happens twice.
Leave this empty and the rule runs on everything. Or add conditions, and it only runs when they all hold true at once.
Send invoices one way and purchase orders another. Or set up a rule that only ever touches bank statements.
Whether the document added up or got flagged. Handy when one rule covers both paths but you want them to end up in different places.
Over a number, under a number, or exactly a number. The obvious use: treat the big ones differently from the small ones.
And if a condition ever doesn't make sense — you renamed something, or a document simply hasn't got that field — the rule doesn't run. It doesn't guess and it doesn't fire anyway. The same instinct as everything else here: when in doubt, do nothing rather than something wrong.
This is the part people don't expect. A rule that hits a document needing your attention doesn't fail, and it doesn't give up. It stops, exactly where it is, and waits for you.
It's read, and the sums are done. The lines don't quite make the subtotal, so it's flagged for you. Your rule starts running.
The rule gets as far as “this one needs a person” and parks there. Nothing is sent. Nothing is half-sent. It simply holds its place.
You open it, see the page beside the numbers with the problem already pointed out, correct the line and save. That's your whole involvement.
The moment you save, the rule picks up from exactly where it stopped and finishes the job — lays the document out and sends it on. You don't press anything. You don't remember to come back to it.
One rule, both paths. You don't build one thing for the good days and another for the awkward ones.
A document gets laid out the way the receiving system wants it, and then it gets delivered. You set up the places it can go once, and use them from any rule.
Sent straight to your system the moment it's ready. If it needs to know the message really came from us, it can check the signature we put on every one.
Onto your own server, over a secure connection, named however you like. The workhorse — most finance systems will happily pick a file up out of a folder.
Attached to a message, to whoever needs it. For the people in the loop who don't have a system for it to go into — they just want the file.
You'd think you'd need a separate rule for invoices, another for credit notes, another for statements — because each one comes out in a different layout.
You don't. Say “lay it out for the system it's going to” and it works out the right layout for each document as it goes, based on what that document actually is. One rule covers the lot.
And if it can't find the right layout for something? It stops. It will not squeeze a credit note into an invoice's shape and hope nobody notices.
Things fail. A server reboots, a connection drops, a password expires. What matters is what happens next — and what you're told about it afterwards.
Up to five times, waiting a little longer between each go rather than hammering a machine that's already having a bad day. Most outages sort themselves out well inside that.
If the file was laid out fine and only the sending failed, it doesn't go back and redo the laying out. It picks up at the step that actually broke.
What ran, when, what it produced, and the actual reason it failed — kept against the document, not lost in a log somewhere. So “what happened to that bill?” has an answer.
And a rule that's genuinely stuck stays stuck loudly, rather than being marked done. Nothing here quietly decides a failure was close enough.
The moment you let something deliver files to your server, it's holding a password. That's worth being fussy about.
Most of this is a five-minute conversation. Tell us what system you're feeding and what you'd want to happen when something doesn't add up, and we'll show you the rule that does it.