Privacy Policy

Version 1.7 · Effective 10 September 2026

1. What this policy covers

Backbone Business Solutions Inc., trading as Backbone Solutions ("we", "us", "our"), is incorporated in British Columbia, Canada, incorporation number BC1601923. This policy covers Backbone Atlas, our procurement and accounts-payable platform, and the connections Atlas makes to accounting systems such as QuickBooks Online, Xero, Microsoft Dynamics 365 Business Central and Sage Accounting.

It also covers this website, sourcetopay.ca, and its demo request form. Backbone Solutions' general company website is backbonesolutions.ca. Its privacy policy is at backbonesolutions.ca/privacy.html. Where the two differ in relation to Atlas or this website, this policy governs.

2. Two roles, and why the difference matters

This is the distinction a privacy officer checks first, and it runs through everything below.

When a customer's people use Atlas, we are a processor (a "service provider"). The customer decides what goes into their workspace, why, and how long it stays. We hold and process it on their instructions. Personal information inside a workspace — their staff, their suppliers' contacts — belongs to their relationship with those people, not ours, and their privacy policy governs it.

For workspace data, our obligations to the customer are set out in the data processing agreement we provide when the customer signs. For that data, the data processing agreement prevails over this policy.

When you visit our website, ask for a demo, or administer a customer's account with us, we are a controller. That is our own relationship with you, and this policy governs it.

Sections 3 and 11 concern our controller role. Sections 4 to 6 and 8 to 10 concern mainly the processor role. Section 7 covers both.

3. Information we hold as a controller

• If you ask for a demo through our form — your full name, company and work email address (required), and, if you choose to give them, your country, city, current procurement system, whether you want Atlas standalone or integrated, and a message. The form also records the page you came from (the referring page).
• If you email us — your name, email address, organisation, and whatever you choose to write to us.
• If your organisation becomes a customer — the business contact details of the people who administer the account, and billing details.
• Our website's server logs — like any web server, ours keeps standard access logs: your IP address, the pages you requested, and your browser type. We keep them for security.
• Our website — we use no analytics, advertising, or session-recording tools of any kind. There is no Google Analytics, no tag manager, no advertising pixel and no session recorder on this site. It loads no third-party scripts or fonts.

How a demo request reaches us. The form's handler, hosted by HostPapa, sends your details by email to our enquiry mailbox, [email protected], also hosted by HostPapa. We use them to answer you and arrange a demo. We do not add you to a mailing list.

Cookies and browser storage. This website sets no cookies. If you choose a colour theme (light, dark or green), that choice is saved in your own browser's local storage so the site remembers it. It is never sent to us. Clearing this site's data in your browser removes it.

What we use it for, and our lawful basis. Privacy laws in the EU and UK require us to state a legal basis for each use. The same list tells you, wherever you live, why we hold what we hold.

We rely on consent only where consent is the basis — for example, marketing email. We do not currently send marketing email. Where we do rely on consent, you can withdraw it at any time.

We do not sell personal information, and we do not use it for advertising.

4. Information inside a customer's workspace

An Atlas workspace typically contains the names, work email addresses and roles of the customer's own staff, and business contact details for their suppliers, together with requisitions, purchase orders, invoices and approval records.

If you are an employee or supplier of an organisation that uses Atlas and you want your information accessed, corrected or deleted, please ask that organisation. They control it and we act on their instructions. If you approach us directly we will refer you to them and let them know you asked.

Two things worth stating because they are often asked:

• Erasure does not destroy the audit trail. An administrator can erase a person's name, email address and login while keeping the record of what they approved; the trail then reads "Former user". An audit needs to know that an approval happened and at what level — it never needed the person's email address.
• The customer can export everything at any time, without our assistance.

Support tickets. A ticket raised inside Atlas records the text the user writes and diagnostic context: the page, the build and schema version, the browser and device, and a correlation id that links the ticket to our logs. Retention periods ship unset, so ticket content is kept for as long as the workspace exists, unless the customer's administrator sets a shorter period.

Supplier catalogues, where a customer uses that part of Atlas. This lets your people shop on a supplier's own website — Amazon Business, Staples, ZAGENO — at your negotiated prices, and bring the basket back into Atlas as an order.

• The supplier is told who is shopping. When somebody opens a catalogue, Atlas passes their name and work email address to that supplier's site. That is how it knows to show your negotiated pricing rather than the public price. It is the only personal information sent, and it goes to a supplier you have chosen and contracted with — not to anyone we have appointed.
• The basket comes back through the shopper's own browser, not through a back channel between us and the supplier. Atlas accepts it only against a single-use, time-limited identifier it created when the shopping trip started, and refuses a basket that has already been brought back, has expired, or does not match a trip it started.
• Nothing is ordered without somebody pressing a button in Atlas. Leaving a supplier's site with a basket is not placing an order.

Supplier spend reporting, where a customer uses that part of Atlas. With your permission Atlas can read your own account with a supplier — today, Amazon Business — to show what your organisation actually spent there, including purchases that never went through Atlas at all.

• Atlas only reads. Nothing is sent to the supplier and nothing in your account is changed.
• What is read is transaction detail: what was bought, amounts, invoice numbers and dates, and the payment method as the supplier describes it — typically a card brand and its last four digits, such as "Visa ending 4242". Atlas never receives a full card number and cannot make a payment with any of it.

Peppol e-invoicing, where a customer uses that part of Atlas. Peppol is the international network many countries now require electronic invoices to travel on.

• Nobody can join Peppol directly, and that includes us. Documents reach the network through an accredited access point. We are not one. None is contracted today, so Peppol is not yet live. An accredited access point will be contracted before first use and named in our sub-processor list at that point. It will handle the documents exchanged and the Peppol addresses of both parties.
• Atlas sends purchase orders and receives supplier invoices and credit notes. It does not send invoices — our customer is the buyer, not the seller.

Employee expense claims, where a customer uses that part of Atlas. This is optional, it is off unless a customer has bought it, and it is worth setting out on its own because the information is different in kind from the rest of a workspace — it is about the customer's own staff rather than about their suppliers.

A claim records expenses an identified employee says they incurred: a date, an amount, a currency, a merchant, a description, the account it is coded to, distances travelled where mileage is claimed, who approved or rejected it and any note they wrote — and receipt documents the employee uploads.

• A receipt is stored as supplied and is not read. Atlas performs no text recognition and extracts nothing from receipt images. It calculates a digital fingerprint of each file so that the same receipt claimed twice can be spotted, and that is the whole of what it does with the contents.
• Receipts are not readable by colleagues generally. Elsewhere in Atlas an internal user can open any procurement document, which is right for a tender addendum and wrong for somebody's receipt — a receipt can incidentally show a home address, the last digits of a personal card, or a purchase somebody would reasonably regard as private. Only the employee who uploaded it and the people who approve claims can open it.
• Atlas does not read bank or card feeds for this, or for anything else. Expenses are entered by the employee. No bank, card issuer or card-transaction feed is connected, and none is needed.
• Atlas does not reimburse anybody. An approved claim becomes an amount owed to the employee in the customer's own accounting system, and payment happens there or in their payroll. Atlas records only what that system later reports about whether it was paid.

5. Connected accounting systems

A customer may choose to connect Atlas to their accounting system. This is optional, it is switched off until an administrator turns it on, and it can be disconnected at any time from within Atlas or from within the accounting system.

The systems Atlas connects to are QuickBooks Online, Xero, Microsoft Dynamics 365 Business Central, Oracle NetSuite, Oracle Fusion Cloud ERP (Oracle Financials), SAP S/4HANA, Sage Intacct, Sage Accounting, Sage 300, Sage X3 and BILL. Four are proven against live ledgers today — QuickBooks Online, Xero, Business Central and Sage Accounting. The other seven are built, and each is proven against the customer's own ledger during onboarding. Sage 50 cannot be connected at all — it has no network interface for an online service to use — and Atlas says so in the product rather than leaving you to find out.

These are your relationships, not ours. Where you connect an accounting system, a supplier's catalogue, or your own account with a supplier, you have chosen and contracted with that organisation. We do not appoint them, we cannot use anything that passes through for our own purposes, and Atlas is the pipe rather than a party. The one exception will be a Peppol access point, which we will contract on your behalf before Peppol is first used and which will then appear in our sub-processor list.

Two of them are your own server, not a cloud service. Sage 300 and Sage X3 run on hardware you operate. You give Atlas the address, and the data moves directly between Atlas and that machine with no third party in between. Atlas will not connect to an address inside a private network: it needs an address reachable over the public internet, or an Atlas running inside your own network.

One of them is not a general ledger. BILL is an accounts-payable platform. Atlas reads its accounts, suppliers and the payment status of bills Atlas created, and posts bills and supplier credits to it. Atlas does not read posted account balances from BILL, because BILL does not hold any.

Which accounts Atlas can see at all. Atlas reads amounts only from the accounts a purchase can be coded to: operating expenses, cost of sales, stock and fixed assets. It also reads the names and codes of liability, receivable and income or contra-cost accounts, only so an administrator can nominate the accounts an accrual uses — never their balances or transactions. It does not ask for — and does not hold — your bank and cash accounts, your investments, your equity, or your payroll and wages.

What Atlas reads from the accounting system:

• the chart of accounts, so purchases can be coded to accounts that actually exist;
• cost centres, classes or dimensions used for tracking;
• the supplier list, so a customer does not have to re-key suppliers they already have;
• the payment status of bills Atlas itself created;
• the dates the accounting system will accept a posting for, so Atlas does not try to post into a period somebody has closed;
• a list of balance-sheet liability accounts, so an administrator can choose which one a period-end accrual is credited to. This is the account names and codes only;
• a list of receivable accounts and income or contra-cost accounts, only so an administrator can nominate the two accounts a supplier rebate accrual uses. Again, this is the account names and codes only;
• the amounts already posted to those purchase accounts, by account, cost centre and month, for the current financial year. This is what lets Atlas show a budget beside what the books actually say, including spend that never went through Atlas.

What Atlas writes to the accounting system:

• approved supplier invoices, as coded bills;
• approved purchase orders, so what has been committed is visible before the invoice arrives. A purchase order does not affect the general ledger in QuickBooks Online or Xero — in those systems it is a document, not an accounting entry;
• a period-end journal for goods received and not yet invoiced, which reverses itself on the first day of the next period. This is off unless an administrator turns it on and nominates the account it credits. In Microsoft Dynamics 365 Business Central the journal is prepared and left unposted for someone there to review and post;
• approved supplier credit notes, as supplier credits;
• a standing journal for supplier rebates earned but not yet received, which does not reverse. This is off unless an administrator turns it on and nominates both accounts it uses — Atlas never chooses them — and it posts only a rebate accrual somebody has reviewed;
• a supplier record, only where the bill is for a supplier the accounting system does not already have.

What Atlas never does:

• Atlas does not move money. It cannot make, schedule or authorise a payment. Payment status is only ever read from the accounting system, never written to it.
• Atlas does not read your customers, your sales invoices, your bank feeds, your payroll, your equity, or the balances of your revenue accounts.
• Atlas does not use any of this data for advertising, for resale, or to train any model.
• Atlas does not share it with any other customer. Each customer's data is held in a separate database.

One honest limitation. Three of the supported accounting systems will not let an application ask for particular accounts. Xero's journal feed, QuickBooks Online's reporting and Sage Accounting's ledger-entry feed all answer with a wider set than Atlas asked for. In those three cases Atlas discards everything outside the purchase accounts listed above as it arrives, before it is read or totalled, and none of it is stored — but the wider set does briefly cross the connection. Microsoft Dynamics 365 Business Central, Oracle NetSuite, Sage Intacct, Sage 300 and Sage X3 are asked for the specific accounts and never send the rest at all; BILL is never asked, because it holds no posted balances. We would rather say this plainly than imply a filter we do not control.

Credentials, and a real difference between these systems. Most of them are connected by signing in at the vendor's own site. Atlas never sees your password: it receives a token limited to what Atlas asked for, which you can revoke at your end at any time. That covers QuickBooks Online, Xero, Business Central, NetSuite, Sage Intacct and Sage Accounting.

Five of them offer no such sign-in Atlas can use, so Atlas has to store a credential you type in. BILL, Sage 300, Sage X3, Oracle Fusion and SAP S/4HANA have no equivalent handover:

• BILL — a developer key, an organisation identifier, a user name, and either a console API token or that user's password. Atlas asks for the console API token wherever your BILL plan issues one, because it is scoped to the integration and can be revoked on its own. A password is the whole of that user's account, including whatever it may do with payments, and it keeps working after Atlas is disconnected;
• Sage 300 and Sage X3 — the address of your server, and a user name and password for it. Use a dedicated integration account with the narrowest rights that can create a purchase invoice, never a person's own login.
• Oracle Fusion Cloud ERP — the address of your Oracle environment, and a user name and password. Fusion does support the delegated kind of sign-in and we would rather use it; the reason we cannot is that a Fusion application is registered inside your Oracle identity domain, so the credentials would belong to you rather than to Atlas, and there is nothing for us to register centrally. The same advice applies: a dedicated integration account with the narrowest rights that can create a payables invoice.
• SAP S/4HANA — the address of your SAP system, the client, and a communication user with its password. As with Oracle, S/4HANA does support delegated sign-in and certificate authentication, and we cannot use either for the same reason: they are registered inside your SAP system, so the credentials would be yours rather than ours and there is nothing for us to register centrally. Use a dedicated communication user with the narrowest authorisations that can create a supplier invoice.

Tokens, keys and passwords alike are encrypted before they are stored, are never written into logs, job records or error messages, and are never shown back on screen once saved — not even to the administrator who entered them. Disconnecting deletes them.

What a stored password means, said plainly: unlike a token it cannot be narrowed, it does not expire, and revoking it means changing that account's password in the accounting system itself. If you would rather not do that, choose a system from the first group above.

Personal information in this data. A supplier record may contain an individual's name and contact details — for example a sole trader. We treat that with the same protections as everything else in the workspace, and it remains under the customer's control.

6. Where data is held, and who else touches it

Customer workspace data is held in Canada, in DigitalOcean's Toronto region. Each customer has a separate database. Where a customer's agreement provides for hosting in its own region, we stand up a dedicated cloud instance there when the agreement is signed, and the agreement names the location.

These service providers are involved in operating Atlas and this website:

• DigitalOcean — hosts Atlas, in Toronto, Canada.
• Cloudflare — sits in front of Atlas, providing DNS, TLS and protection against attack, on its worldwide network. Because it terminates the encrypted connection, it decrypts requests and responses at its edge to route and protect them. It does not store workspace data, and the connection onward to our servers in Canada is itself encrypted.
• Backblaze — stores encrypted backups of workspace databases. We are confirming the storage location, and will state it in our sub-processor list once confirmed.
• HostPapa — hosts this marketing website, the demo request form and our enquiry mailbox. It holds no workspace data.

We run no email service of our own. Where a customer sets up email, Atlas sends it through the customer's own mail server. The accounting systems, catalogues and supplier accounts a customer connects are the customer's own relationships (see section 5). A current sub-processor list is available on request, and customers are told before it changes.

7. International transfers

• Atlas data is hosted in Canada. Cloudflare processes traffic to and from Atlas on its worldwide network.
• This website and enquiry emails are handled by HostPapa.
• A regional instance. Where a customer's agreement provides for hosting in its own region, we stand up a dedicated instance when the customer signs. That customer's workspace is then kept in the region named in its order, which also names the hosting provider.

Transfers into Canada. The European Commission has found that Canada provides adequate protection for personal information sent to recipients subject to PIPEDA, Canada's federal private-sector privacy law (Decision 2002/2/EC). The UK recognises the same under its adequacy regulations. Our commercial handling of personal information, including across borders, is subject to PIPEDA.

Other regions. For customers elsewhere, the safeguards for transfers are set out in the customer's data processing agreement. For example, transfers out of Saudi Arabia rely on safeguards under the PDPL transfer regulation, such as SDAIA's standard contractual clauses. An Australian customer that discloses information to us in Canada remains accountable for it under Australian Privacy Principle 8, and the data processing agreement addresses this.

People in Quebec. Personal information collected through this website, including from people in Quebec, is stored and processed outside Quebec: in Ontario, and by the service providers listed in section 6.

Foreign law. Information held in another country is subject to that country's laws, and may be accessible to its courts, law enforcement and national security authorities.

8. Retention and deletion

• Enquiries that do not become customers — kept for 6 months, then deleted.
• Support tickets — kept for as long as the workspace exists, unless the customer's administrator sets a shorter period.
• Customer account and billing records — kept for the term of the agreement, then for as long as Canadian tax and corporate law requires.
• Workspace contents — the customer's decision, not ours. On termination the customer may export everything, and we delete the workspace on request.
• Accounting-system tokens — deleted when the connection is disconnected.

9. Security

• a separate database per customer, so one customer cannot read another's records;
• encryption in transit;
• encryption at rest — customer data is held on encrypted block storage (AES-256), and backups of it inherit that encryption;
• application-level encryption of stored credentials and supplier bank details, under a key held outside the database, so a copied database file discloses neither;
• passwords stored only as salted hashes;
• role-based access, multi-factor authentication, and optional single sign-on;
• a full audit trail that records refusals as well as actions;
• regular backups, verified by being opened and checked rather than assumed.

No system is completely secure. If a breach affects personal information in a customer's workspace, we will notify that customer without undue delay, and in any event within 72 hours of becoming aware of it, and notify regulators as the law requires. Where a customer's agreement sets a shorter period, that period applies.

10. Artificial intelligence

The optional AI assistant is off by default and we cannot switch it on. It requires an API key that the customer obtains themselves from Anthropic or OpenAI, under the customer's own agreement with that provider. That relationship is the customer's, not ours. We hold no shared key, so there is no arrangement under which customer data reaches an AI provider on our account. No customer data is used to train any model.

11. Your rights

Depending on where you live, you may ask to access, correct, delete or port your personal information, to object to how it is processed, or to complain to a regulator. Where we rely on your consent, you may withdraw it at any time. Withdrawing it does not affect what we did before.

No decision about a website visitor or enquirer is made solely by automated means.

Write to our privacy officer, Fariha Kulsum, at [email protected]. We respond within 30 days.

You may complain to the Office of the Privacy Commissioner of Canada or your provincial commissioner, including the Commission d'accès à l'information in Quebec; to your national supervisory authority in the UK or EU; to the Office of the Australian Information Commissioner; or to the data protection authority where you live.

If your request concerns information inside a customer's Atlas workspace, please see section 4 — the customer controls that information and we will refer you to them.

12. Changes and contact

We will tell customers about material changes to this policy at least 30 days before they take effect.

Backbone Business Solutions Inc.
4871 221 Street, Langley, British Columbia, V3A 0J5, Canada
Privacy officer: Fariha Kulsum, [email protected]

See also the Backbone Atlas Terms of Service.