Every business that runs on Ledgerly shares infrastructure and shares nothing else. That is worth being specific about, because “we take security seriously” is not a mechanism.
Application code never talks to the database directly. It goes through a client that adds the company filter to every read, stamps it onto every write, and is driven by the schema itself — so a table added next year is protected the day it is added, not the day somebody remembers. A request for a record id belonging to another company comes back empty, exactly as if it did not exist.
Every reference between records carries the company alongside the id. That closes the gap a filter alone leaves open: a document that belongs to you but points at another company’s customer. The database rejects the reference rather than storing it, so the case where a detail page would render somebody else’s name simply cannot arise.
The company column defaults to a value no company can have, behind that foreign key. Any write that somehow escaped the scoped client would be rejected on the spot instead of landing somewhere quiet where nobody looks for months.
Two automated suites run on every change. One signs up two companies and attacks one from the other — stolen record ids, totals, bulk updates, payments applied to the wrong invoice. The other reads the source code itself and fails the build if any file reaches for the unscoped client without being on a short, justified list.
Any one of these could have a bug. The point of having four is that a bug in one of them is not enough.
There is no payment processing in this product, so no card data ever reaches it. We are not going to list compliance badges we have not earned. And if you find a way across the wall between two companies, that is the most valuable bug report we can receive — it will be treated that way.