The documents are in before the close starts
Point-of-sale receipts arrive at payment and mailbox capture collects the emailed ones, which turns the usual month-end chase into a feed you review.
Accounting automation
Code bank transactions from the receipt, not the descriptor
A bank feed row has an amount, a date and a terminal string. Smartbills attaches the merchant's itemized receipt, so the entry is coded from what was bought.
Smartbills codes bank transactions from the itemized receipt instead of the descriptor, and every field says whether it was read or inferred.
Enriched transactionSource: receipt
Raw descriptorBUREAU EN GROS #0142 MONTREAL QC • $182.09
MerchantBureau en Gros / Staples Canada ULC
Location3400 Rue Jean-Talon O, Montreal QC / store 0142
Line items2 x Toner cartridge 54.99, 1 x Copy paper, case 38.49, 1 x Desk lamp 9.90
TaxGST 7.92, QST 15.80 / split per line
TipNone on this receipt
Payment methodMastercard 2290 / chip
Confidence1.00 / source: receipt
Source: receiptProvenance per field
Categories that still hold next quarter
The merchant is identified before the category is chosen, and the category belongs to the business instead of the string. When we improve the taxonomy, the change applies going forward and never rewrites a client's books.
- Stable taxonomy, with improvements applied going forward
- MCC included, and a taxonomy that holds when the MCC is wrong
- Transfers, fees, refunds and reversals kept out of spend
Claim sales tax from the receipt itself
Tax arrives split the way the point of sale recorded it (per line, when the merchant records it per line) and every claim is backed by a document you already have.
- Tax amounts read from the receipt, never back-calculated
- Original document kept and linked for audit
- Mixed-rate baskets split line by line
Why teams switch
Coding and tax worked out from a total are a guess.
The same supplier ends up in three different accounts over a single year.
Smartbills works out which business the merchant is before it picks a category, and ties the category to that business rather than to the descriptor string, which keeps next quarter's transactions in the same account.
We rebuild input tax credits by applying a rate to the total and hoping it holds up.
GST/HST and QST arrive already split the way the point of sale recorded them, with the original document attached. The ITC claim rests on evidence you already hold instead of on arithmetic.
The first week of the close goes to chasing documents that already existed somewhere.
The point of sale sends the receipt at payment and mailbox capture collects the rest. Documents are attached before the close starts.
The API, into your ledger
Two ways to ship it, both on the same receipt data: post the coded entry from your own ledger, or let users open the receipt inside your product.
Send the transaction
Descriptor, amount and timestamp. Nothing about the person who paid.
Receipt first
When a network merchant issued the receipt, line items and tax come straight from the sale.
We code the entry
Category and tax split, with transfers and fees separated out and each field showing its source.
You post it
Your chart of accounts, your rules and your own threshold for what posts without review.
Embedded receipts, nothing to build
Drop in the component
The source document opens from any line in your ledger or bank feed.
Connect the mailbox
Your client authorizes once, and emailed invoices join the POS receipts in the same feed.
Documents before the close
Matched, attached and kept. Month-end becomes a review, not a chase.
Late documents catch up
When a receipt lands after the statement, a webhook recodes the entry.
The products that do the work.
Each product works on its own, and when you run two, the same record carries from the receipt to the ledger entry.
Transaction enrichment
Resolve a card descriptor into a business your customer recognizes, with logo, location and category, plus the itemized receipt when the merchant sent us one.
Accounting automation
Accounting automation software that codes each transaction and posts the journal entry to your accounting software the day it happens.
Embedded receipts
Itemized receipts from the merchant's point of sale, shown inside your own app under the transaction they belong to. For banks, fintechs, retailers and any app built on the API.
FAQ
Frequently asked questions
What people ask us before they sign up.
A categorization API gives you one field, and that field is only as good as the ones underneath it. Smartbills first works out which specific business it was and at which location, then attaches the category to that business. For merchants on our network there is no string to classify, because we have the receipt.
They are resolved the usual way, by parsing the descriptor against a corpus plus a model, and the response tells you so. Provenance comes back for every field with a confidence score you can set thresholds on. An entry coded from a document can always be told apart from one coded from an estimate.
No. Improvements apply going forward only. A reclassification that quietly moves last year's coffee to a new account is a reconciliation problem pretending to be an upgrade. The taxonomy is versioned and closed periods keep the coding they closed with.
Yes. The receipt is kept and linked to the transaction. The entry, the amount and the supporting document form one record instead of three systems an auditor has to join by hand.
In region. Canadian data is resident in Canada and European data stays in Europe. Enrichment only needs the descriptor, the amount and the timestamp, and it never receives cardholder identity.
Get started
Code the entry from the document
Send us a backfill of historical transactions and we'll tell you how many match a real receipt before you write a line of code.