Remit

Services

The decision worth arguing about

The non-obvious decision is refusing to let the queue be the source of truth for a payment run, which is the opposite of how every other worker in this library is built. SQS standard delivery is at-least-once: under the right combination of visibility-timeout expiry and consumer slowness, the same message is delivered twice. Everywhere else in this catalogue that is a non-event, because the worst outcome is a duplicated webhook or a repeated email. In accounts payable it is a double payment, and a double payment is the failure mode that ends careers and gets an entire system torn out. So the payment run is a state machine in Postgres with transitions enforced by a check constraint and a unique partial index on (payment_run_id, state) that makes a second transition into RELEASED physically impossible; SQS carries nothing but a wake-up signal saying a run may need attention. If a message is delivered twice, the second worker takes the advisory lock, reads the state, sees the run is already released and exits. If a message is lost entirely — which SQS also permits in principle — a two-minute sweeper finds the pending run and processes it, so the failure mode is a short delay rather than a missing payment. The cost of this design is that we have given up horizontal throughput on the payments path: the run is effectively serialised per bank account, and a batch of forty thousand instructions takes minutes rather than seconds. For AP that is the right trade every time. Two smaller notes: Textract's AnalyzeExpense handles header fields well and line items inconsistently across supplier layouts, so we learn a per-supplier template from the first few human-corrected invoices and use Textract as the fallback for unseen layouts rather than the primary path; and the payment file bucket carries S3 Object Lock so that a generated file cannot be altered between approval and transmission.

Services

The decision worth arguing about

The Azure decision that shapes the deployment is not about documents or workflow — it is about a single IP address. Almost every corporate bank that accepts a payment file over SFTP allowlists the source IP, and several that offer APIs allowlist as well. That means the payments service needs a stable, dedicated egress address, and on Azure Container Apps a stable outbound IP requires a NAT Gateway attached to the subnet, which in turn requires the Container Apps environment to be a workload-profiles environment inside your own VNet rather than the default consumption-only environment. Workload profiles bill a per-node baseline whether or not anything is running, so this one requirement — a fixed IP the bank will accept — puts roughly $150 to $200 a month of floor under the Azure deployment that the AWS shape avoids, because on AWS a NAT Gateway with an Elastic IP is a smaller fixed charge and Fargate needs no equivalent environment upgrade. It is worth knowing before you compare the two numbers below and conclude Azure is simply more expensive. There is a second-order benefit we take while we are there: because the environment is VNet-integrated anyway, PostgreSQL runs with a private endpoint and no public networking at all, which for a system generating payment instructions is a materially better posture and the sort of thing an auditor asks about. Document Intelligence's prebuilt invoice model replaces Textract with broadly comparable behaviour and the same caveat about line items; we run the same per-supplier template learning on top of it, so the extraction layer is genuinely portable between the two clouds rather than being rewritten.