What is the supported way to get transactions in?
SapphireOne's documented mechanism for bringing outside data in is Sapphire Gateway II, described in the vendor's own knowledge base. It is an administrator-run import and export facility working from template layouts and tab-delimited files, with a controlled data entry mode. It is a file mechanism rather than a REST API, which is why the shape of the file matters more than anything else in this exercise. SapphireOne publishes a summary at its Gateway II documentation page.
Why not just key the statement?
Because the information you need was available weeks earlier and got thrown away. The statement gives you a merchant descriptor and an amount; the department, the project, and the reason live in somebody's memory, and the receipt is in a wallet or a photo roll. By the time the accounts team is keying, every ambiguous line becomes an email, and the answers arrive slower than the deadline does.
How do you import card transactions instead?
- Code at the point of spend. The cardholder picks the account and department or project in Vergo when the charge posts.
- Attach the receipt. Photographed immediately and held against that transaction.
- Approve. The manager reviews in Vergo, so corrections happen before anything is exported.
- Export and load. Vergo generates a custom-built export matched to the format SapphireOne expects, and an administrator loads it through Gateway.
What has to be right in the file?
Gateway works from template layouts, so the export must match the template your organisation uses: the columns your chart of accounts requires, in the order the template expects, with the delimiter Gateway is configured for. Vergo builds the export against your actual template rather than shipping a generic file, because a near-miss layout fails at load and sends the accounts team back to the spreadsheet — which is the outcome the whole exercise exists to avoid.
Who runs the import?
Gateway is an administrator function by design, and that is a control rather than an obstacle. The people spending money never touch the ledger; they code in Vergo. The administrator loads a batch that has already been approved and can be inspected as a file before it goes in, so segregation of duties survives the automation.
What about GST and supplier detail?
Australian users generally want the tax treatment and supplier identification carried in the same batch, not fixed afterwards by journal. Those fields are captured with the charge in Vergo and carried into the export in the positions your Gateway template expects, so the tax coding arrives with the transaction rather than being reconstructed at BAS time from a pile of receipts and a bank statement.
What does this change month to month?
The accounts team reviews instead of reconstructing. Coding was done by the person who made the purchase, receipts are attached, approvals are recorded, and the Gateway load is the last step of a finished process rather than the whole project.
What is Sapphire Gateway II?
SapphireOne's documented import and export facility, run by an administrator from template layouts using tab-delimited files. The vendor publishes a summary of it in its knowledge base.
Is Gateway II an API?
No. It is an administrator-run file import and export built on template layouts, not a REST API that third-party software connects to directly.
What does Vergo produce for SapphireOne?
A custom-built export matched to the format SapphireOne expects, with each card charge already coded and receipted in Vergo, ready for an administrator to load through Gateway.
Does the coding have to match our chart of accounts?
Yes, and that is the setup work: the export is built against your template and account structure so the batch loads cleanly the first time.
