ERP
Rillet
Connect your AI to Rillet
Controllers, revenue accountants, and finance leads close the books in Rillet, but answering questions about invoices, journal entries, and recognized revenue still means running reports and stitching periods together by hand. AI can answer in seconds, but only if it respects closed periods, posted entries, and the approval steps finance relies on before anything is written back.
Why it matters
Capabilities that matter most for Rillet
01
Over 40 ready-made finance lists
Install summary and matrix lists for Rillet journals, invoices and bills, so close and revenue reporting are ready on day one.
02
Rillet beside billing and CRM
Join Rillet with Stripe, Salesforce or HubSpot lists to reconcile revenue and receivables in one place.
03
Governed AI for finance
MCP tools answer within per-user and per-team security and field redaction, so AI sees only the ledgers each role should.
Use cases
Example AI Use Cases for Rillet
scenario
-
Customer billing emails live in Rillet, and many of those people never make it onto your Constant Contact lists. Bringing them across means comparing two sets of addresses, removing duplicates, and deciding what consent you can honestly record.
What popdock provides
--
Name a Constant Contact list, and optionally part of a customer name, and it reads the customer emails in Rillet, removes duplicates and checks each one in Constant Contact. Existing contacts are counted and left unchanged; only missing addresses become candidates, shown with the Rillet customer name and email type. You confirm the additions and whether these people gave marketing consent, and permission is set only to what you confirm. The list is never created, invalid addresses are skipped and listed, failures are not retried without asking, and Rillet is only read.
Business outcome
---
Your billing customers become part of your marketing audience, added once and with consent recorded as you state it.
scenario
-
When a campaign is meant to drive renewals or upsells, the evidence sits in Rillet invoices and contracts, while the clicks sit in Constant Contact. Lining them up by email and date, and separating new revenue from invoices that would have arrived anyway, is a job most teams skip.
What popdock provides
--
Name the Constant Contact campaign, and optionally an attribution window, 60 days by default, and it lists each clicker with their first click date and links. Clickers are matched to Rillet customers by exact email, and the invoices and new contracts dated in the window after each click are gathered, with totals kept per currency. Customers whose recurring invoices look unchanged are called out, since that revenue was likely coming anyway. It states clearly that this is correlation within a time window, not proof, and it only reads.
Business outcome
---
You see which invoices and contracts followed a campaign, with routine recurring billing called out instead of counted as a win.
scenario
-
If a customer's billing address in Rillet has started bouncing, invoices and payment reminders go unread and the balance quietly ages. Constant Contact already knows which addresses bounce, but nobody compares that with the addresses finance sends invoices to.
What popdock provides
--
Pick a look-back period, 90 days by default, and it collects the addresses that bounced or unsubscribed in Constant Contact and matches them exactly to Rillet customer emails, never on name or domain. For each match you see whether invoices and reminders are sent automatically, the amount due by currency and whether anything is overdue, with hard bounces first. Unsubscribes are labelled as a marketing opt-out, not a dead address. It recommends confirming a new billing email where a hard bounce meets an overdue balance, and changes nothing.
Business outcome
---
Finance finds the invoices likely going unread and fixes the billing address before the balance ages further.
scenario
-
Before a renewal or collections conversation, you want one picture of the customer: open and overdue invoices and ARR trend in Rillet, and whether they still open your emails in Constant Contact. Rillet cannot search customers by email, so even finding the account takes digging.
What popdock provides
--
Give an email address, and optionally a look-back period, 90 days by default, and it finds every Rillet customer using that email, saying so if more than one shares it. You get open and overdue invoices with totals per currency, never mixed, and the latest ARR with its three-month direction. From Constant Contact come permission, sends, opens, clicks, bounces, unsubscribes, lists and the latest note. A short read-across connects the two, names that differ are both shown, and nothing is changed.
Business outcome
---
You go into a renewal or collections call knowing the customer's billing position and how engaged they are.
scenario
-
Collections tends to treat every overdue Rillet customer the same, yet some are reading every email and simply late, while others have gone silent or have an address that bounces. Telling them apart means checking each billing contact's recent email activity by hand.
What popdock provides
--
Optionally set a minimum amount due and a look-back period, 30 days by default, and it groups overdue Rillet invoices by customer with the count, oldest due date and amount per currency. Every email on file for each customer is checked in Constant Contact for opens, clicks and bounces, matched exactly and never on company name. Each customer is classed as engaged but unpaid, silent, or unreachable, and a phone call is recommended for the last two. Both systems are left exactly as they are.
Business outcome
---
Collections can tell an unresponsive customer from one who is simply late, and choose the right next step for each.
scenario
-
Churn rarely arrives without warning: contacts stop opening emails or opt out months before a customer cancels. But ARR lives in Rillet and engagement lives in Constant Contact, so the warning signs go unnoticed until the renewal is already lost.
What popdock provides
--
Choose a month, the latest in the waterfall by default, and a look-back period, 90 days by default, and it reads every Rillet customer carrying ARR and notes those whose ARR fell over three months. All of each customer's contacts are checked in Constant Contact, and the customer is classed as opted out, silent, unreached or engaged. You get every customer that is not engaged, ranked by ARR, with ARR totals per class and currency, and customers that are both disengaged and shrinking highlighted. It only reads.
Business outcome
---
You see which recurring revenue is at risk, ranked by value, while there is still time to step in.
scenario
-
A marketing email offering an upgrade lands badly when the customer is two invoices overdue in Rillet. Marketing rarely sees that context, and pasting billing summaries into Constant Contact contacts by hand is not something anyone keeps up.
What popdock provides
--
Give part of a Rillet customer name, and optionally one contact email, and it summarizes open and overdue invoices, amount due per currency, latest ARR and any contract end date in a short, factual note with no judgement words. The customer's emails in Rillet are matched to Constant Contact contacts, and no contact is ever created. You see the note and the contacts it will go on before anything is written. Notes are added once per contact after your yes and read back, and an account with nothing owing still gets a note saying no open balance.
Business outcome
---
Marketing sees a customer's billing context before contacting them, so offers do not land on accounts in trouble.
scenario
-
Your billing contacts in Rillet and your Mailchimp audience drift apart as customers are added. Closing the gap means comparing two exports by email, and the risk is real: re-adding someone who unsubscribed or was cleaned overrides their consent and can hurt your sender reputation.
What popdock provides
--
Name the Mailchimp audience and it compares every Rillet customer email with every member, dropping anyone already present in any status, including unsubscribed and cleaned. You get a table of the emails to add with their Rillet customer, and nothing is written until you confirm, with any rows you remove left out. New members are added as pending by default so Mailchimp sends its opt-in confirmation, and subscribed is used only when you say you already hold consent. Each address is read back and reported as added or failed, and Rillet is never changed.
Business outcome
---
Your audience covers your paying customers without ever re-adding someone who opted out.
scenario
-
A renewal campaign needs the right contacts: customers whose Rillet contracts end soon and who still subscribe in Mailchimp. Building that segment by hand means filtering contracts by end date, finding each customer's emails, checking subscription status and avoiding people already in the segment.
What popdock provides
--
Name the audience and static segment, and optionally how many days ahead to look, and it reads Rillet contracts ending in that window, skipping closed or canceled ones, and gathers the customers' emails. Only contacts already subscribed in Mailchimp and not yet in the segment are kept, and the rest are listed with the reason they were left out. It refuses saved, condition-based segments and never creates one. After you confirm, the contacts are added and the segment is read back. It sends nothing and adds no new audience members.
Business outcome
---
Your renewal segment holds every reachable renewing customer, and nobody who unsubscribed is pulled back in.
scenario
-
Collections leans on email reminders, but a reminder sent to an address that bounced or unsubscribed never lands. Checking means listing overdue invoices in Rillet, finding every contact email for each customer, then looking each one up in Mailchimp for its status and recent bounces.
What popdock provides
--
Optionally set a minimum amount due, and it groups overdue Rillet invoices by customer with the total owed per currency and the oldest due date. Each contact email is checked in Mailchimp for audience status and hard bounces in the last 180 days, and classed as reachable, unsubscribed or undeliverable, with addresses not in Mailchimp kept separate. Customers with no reachable email are flagged at the end. It only reports: no invoice is marked, no payment is recorded and nobody is contacted.
Business outcome
---
Collections knows up front which overdue accounts need a phone call or a new contact, not another email that will bounce.
scenario
-
Knowing how well a Mailchimp audience covers your customers means lining up every Rillet customer email against the audience. By hand it is slow, case and spacing differences hide matches, and people who unsubscribed or are still pending get lumped in with everyone else.
What popdock provides
--
Name the audience and it reads every Rillet customer email and the full membership in one pass, matching addresses regardless of case or spacing. The report shows totals, the customer emails missing from the audience, members who are unsubscribed or cleaned, and those still awaiting opt-in. If fewer members were read than the audience holds, it says the comparison is partial and how many rows it read. It reports only and never adds anyone.
Business outcome
---
You see exactly which customers your audience misses or cannot reach before you plan a campaign or an import.
scenario
-
A campaign report gives you opens and clicks, but not which of those people pay you or how much. Answering that means exporting campaign activity, matching emails to Rillet customers and looking up each customer's ARR, so most teams never connect engagement to revenue.
What popdock provides
--
Name a Mailchimp campaign and it reads the headline numbers, then everyone who opened or clicked and the links they clicked, ignoring bounces. Engaged emails are matched to Rillet customers, and each customer's latest ARR and status come from Rillet's ARR history. You get a table sorted by ARR, totals per currency with no mixing, and a count of engaged people who are not customers. A customer with no ARR history shows as none recorded rather than zero, and nothing is changed.
Business outcome
---
Marketing can show which paying accounts a campaign reached and how much recurring revenue they represent.
scenario
-
An unsubscribe from a paying customer can be an early sign of trouble, but Mailchimp does not know who pays you. Spotting the risky ones means matching each unsubscribe to a Rillet customer and checking their ARR and contract end date, which rarely happens before the renewal conversation.
What popdock provides
--
Pick a date range, the last 30 days by default, and it reads Mailchimp unsubscribes and matches each email to Rillet customers. For every matched customer it pulls the latest ARR and the nearest contract end date. The table is sorted by ARR with the campaign and reason, showing not given when no reason was left, and it totals the ARR affected per currency and names campaigns that drove more than one customer away. It is read-only and never resubscribes anyone.
Business outcome
---
Account owners hear about unhappy paying customers in time for a real conversation, ranked by the revenue at stake.
scenario
-
To understand one customer you need their revenue position from Rillet and their email engagement from Mailchimp, which live in different systems. Pulling ARR, contracts, credit memos, audience status and recent activity together takes several searches, and an email shared by two Rillet customers is easy to miss.
What popdock provides
--
Give an email address and it finds every Rillet customer that contact belongs to, then reads current ARR with the change from last month, contracts with their end dates, and credit memos in the lookback window. From Mailchimp it reads audience status, open and click rates and recent activity counts. Each customer is reported separately with no ARR added across them, and the report ends with one line of interpretation, such as high ARR with no opens in 90 days. Neither system is changed.
Business outcome
---
You see what a contact is worth and whether they still listen, in one view before any account conversation.
scenario
-
Renewals at risk often go quiet first: contacts stop opening email, unsubscribe or start bouncing. Spotting that means listing contracts ending soon in Rillet, finding each customer's contacts and checking every one in Mailchimp, which nobody has time to do across a whole quarter.
What popdock provides
--
Choose how many days ahead to look, 90 by default, and it reads open Rillet contracts ending in that window and each customer's contact emails. Every email is checked in Mailchimp for status, opens, clicks and bounces over the last 90 days. Each contract is rated engaged, silent or unreachable based on its best contact, with the count and value per rating and no totals across currencies. A failed lookup is marked unknown rather than guessed, and nothing is changed.
Business outcome
---
You see which upcoming renewals have gone quiet while there is still time to reach the customer another way.
scenario
-
Entering a vendor bill means finding the vendor, checking the expense number has not already been entered, remembering which GL account that vendor is usually coded to and working out the due date from payment terms. A duplicate bill or a miscoded expense is easy to miss until month end.
What popdock provides
--
Give the vendor, expense number, amount and description, and it finds the vendor in Rillet without ever creating one, then checks for an existing bill with the same number. The GL account and currency are taken from the vendor's past bills, the account is confirmed active, and the due date comes from the vendor's payment terms. You see the full bill, with a warning when the coding is a guess, and it is created once only after you confirm. The stored bill is read back, and a bill split across accounts must add up to the amount.
Business outcome
---
Vendor bills are entered once, coded consistently and due on the right date, with no duplicates to reverse later.
scenario
-
Recording a bill payment means finding the bill, adding up its lines and tax because Rillet bills carry no total, subtracting earlier payments and picking the right bank account. Get the balance wrong and you overpay a vendor or leave a bill showing open.
What popdock provides
--
Give the expense number, and optionally an amount, date and cash account, and it finds the one matching Rillet bill and works out its total from the lines and tax, less payments already recorded. It refuses a payment larger than the unpaid balance and stops if the bill is already paid. If you give no account, it offers active bank or cash accounts. You see the totals, this payment and what remains, and the payment is recorded once only after you confirm, then read back with the new balance. The bill itself is never edited.
Business outcome
---
Vendor payments are recorded against the right bill for the right amount, with no overpayments or stale balances.
scenario
-
When a customer pays, you have to find the invoice, check what is still owed and what was already recorded, and post the payment to the right cash account. An overpayment or a payment against the wrong invoice throws off receivables until someone notices.
What popdock provides
--
Give the invoice number and amount, and optionally a date and cash account, and it finds the exact Rillet invoice with its customer and the payments already recorded. A payment larger than the amount due is refused, and a fully paid invoice stops the process. If no account is given, it offers active bank or cash accounts. You see the invoice total, the amount due and the balance after this payment, and the payment is recorded once only after you confirm. It then shows the new payment and the updated amount due, and never edits an existing payment.
Business outcome
---
Customer payments land on the right invoice with the right balance, and overpayments never get posted.
scenario
-
Building an aging report means pulling every open invoice from Rillet, working out days past due, sorting them into buckets and keeping currencies apart. Drafts and voids sneak into the totals, and the customers who most need a call get lost in the table.
What popdock provides
--
Give an as-of date, and optionally one customer, and it reads open Rillet invoices with an amount due, leaving out drafts and voids and saying how many it excluded. Days past due are worked out from the due date, or the invoice date when there is none, and sorted into current, 1 to 30, 31 to 60, 61 to 90 and over 90. You get a separate aging per currency with bucket totals and the top five collection priorities, each with its oldest invoice and a reason. It only reads.
Business outcome
---
Collections starts each day knowing which customers to chase first and how much is at stake in each currency.
scenario
-
Explaining why ARR moved from one month to the next means lining up every customer in both months, sorting them into new, expansion, contraction and churn, and checking the bridge adds up. By hand it takes hours, and a customer who looks churned may simply have a data problem.
What popdock provides
--
Pick a month, and optionally the month to compare against, and it reads the Rillet ARR history for both, checking the date format first. Each customer is classed as new, expansion, contraction, churned or flat within the same currency. You get an ARR bridge per currency that is checked to add up, the five largest movers in each category and net revenue retention. A churned customer who still has an active contract is flagged as a likely data issue, and if either month has no data it stops rather than calling everyone new or churned.
Business outcome
---
You explain the month's ARR change customer by customer, with a bridge that reconciles and net retention ready to share.
scenario
-
Planning a payment run means finding every bill due soon or already overdue, then working out what is actually unpaid. That is harder than it sounds because Rillet bills carry no total, so you add up lines and tax and subtract earlier payments for each one.
What popdock provides
--
Choose how many days ahead to look, 14 by default, and optionally a vendor, and it reads Rillet bills due in that window plus anything already overdue. Each bill's total is built from its lines and tax, less payments recorded, and fully paid bills drop out. You get overdue bills first, then the rest by due date, with unpaid totals per currency split into overdue and due soon. Draft and void bills are excluded and counted, and nothing is paid or changed.
Business outcome
---
Your payment run starts from an accurate list of what is owed and when, with overdue bills at the top.
scenario
-
Renewals slip when nobody sees them coming. Getting ahead means listing Rillet contracts ending soon, checking what is on each, finding the customer's current ARR and noticing any unpaid balance before the renewal call, all from separate screens.
What popdock provides
--
Choose how many days ahead to look, 90 by default, and optionally a customer, and it reads Rillet contracts ending in that window with their items. Each customer's latest ARR and any open invoice balance are added. You get a list ranked by ARR with days left, total value, products and quantities, the open balance and a short note such as falling ARR. Canceled or ended contracts are left out and counted, currencies stay separate, and nothing is changed.
Business outcome
---
You see every upcoming renewal ranked by revenue at stake, with unpaid balances known before the conversation starts.
scenario
-
A full picture of one customer means opening their Rillet contracts, items, ARR history, invoices, payments and credit memos one at a time. Simple questions, such as what they owe, what they are worth and whether anything looks wrong, take an afternoon to answer.
What popdock provides
--
Name the customer and it finds the one matching Rillet record, listing matches and stopping if there are several. It reads contracts with their items and products, twelve months of ARR, invoices, payments received and credit memos. You get one page with contracts, the ARR change over the year, and billed, paid, credited and open balance per currency, plus flags for overdue invoices, contracts ending within 90 days, falling ARR and credit memos not tied to an invoice. It reports what the data says without speculating, and changes nothing.
Business outcome
---
You understand a customer's contracts, value and balance on one page before any billing or renewal conversation.
scenario
-
Turning the income statement, balance sheet and cash flow statement into a short management pack means pulling three reports, picking out the key figures and checking that the balance sheet balances. It eats hours at month end, and a mismatched period can go unnoticed.
What popdock provides
--
Give the period end, and optionally its start, and it reads the Rillet income statement, balance sheet and cash flow statement, saying plainly if the income statement covers a different period and labelling it as a substitute. It derives revenue, gross margin, operating expenses, net income, cash, receivables, payables, equity and cash flow totals, and checks that assets equal liabilities plus equity. You get a headline table, three to five observations tied to specific numbers, and anything that did not reconcile. Line items keep their names, nothing is forecast and nothing is posted.
Business outcome
---
Month end produces a short, checked management pack in minutes, with any reconciliation gap called out.
scenario
-
Reviewing journal entries for a period means scanning for entries that do not balance, lines on inactive accounts, manual postings with no source document and reversals that never happened. Done by eye across hundreds of lines, the risky ones are easy to miss before close.
What popdock provides
--
Give a date range, and optionally one account, and it reads the Rillet journal entries and lines in the period together with the chart of accounts. Each journal is checked for imbalance per currency, unknown or inactive accounts, manual entries, overdue reversals, large round manual amounts and weekend posting. You get counts per check and each flagged journal with its lines, errors first and review items after. Flags are worded as reasons to look, not proof of error, and nothing is fixed or posted.
Business outcome
---
Close reviews focus on the few entries that genuinely need a second look, found before the books are locked.
scenario
-
Knowing where money went means combining vendor bills, card charges and reimbursements, which sit in different places in Rillet, then totalling by vendor and GL account. Done in spreadsheets, miscoded spend and unexplained large lines rarely surface.
What popdock provides
--
Give a date range, and optionally a vendor, and it reads Rillet bill lines, card charge items and reimbursements in the period with vendor and account names. You get top vendors with spend split by source, spend by GL account with its share of the period, and notable items such as a vendor coded to several unrelated accounts, a single line over 10 percent of the total, or lines with no description. Amounts are reported per currency with tax shown separately, and nothing is changed.
Business outcome
---
You see where spend really goes by vendor and account, with miscoded or unusual items surfaced for review.
scenario
-
Every Shopify payment needs to land against the right Rillet invoice, but matching captures to invoices by order number and posting them one by one is slow. Post one twice, against a paid invoice or for more than is owed, and receivables stop making sense.
What popdock provides
--
Pick a date range, yesterday by default, and a clearing account, and it reads successful Shopify sales and captures and finds the Rillet invoice for each order, trying the order number with and without the hash. Payments are sorted into ready, no invoice, already paid, over amount and currency mismatch, and only the ready group is posted. It confirms the account is active, skips payments that look already recorded, and stops posting once an invoice is fully paid. Nothing is posted until you confirm, and Shopify is never changed.
Business outcome
---
Shopify cash is applied to the right invoices, with no double postings or overpayments to unwind.
scenario
-
When Shopify orders do not reach Rillet, receivables are understated and someone has to create invoices by hand. That means checking each order against existing invoices, finding the right customer by email and splitting tax from the total, and a second pass easily creates duplicates.
What popdock provides
--
Choose a date range and a Rillet product, and it reads Shopify orders, skipping canceled and voided ones, and keeps only those with no Rillet invoice under the order name. Each order's customer is matched by email, or a fallback customer you name, and orders with no customer are listed but not created. You see each invoice with net, tax and total before anything is written. After you confirm, each is created once as a receivable-only invoice keyed to the Shopify order, and invoices are re-read first so a second run does not duplicate.
Business outcome
---
Missing Shopify sales reach your Rillet receivables, each tied to its order, with no duplicate invoices.
scenario
-
Each Shopify refund should become a Rillet credit memo applied to the order's invoice, but finding the refunded amount, the invoice and whether a memo already exists takes several lookups per refund. Book one twice and your receivables are understated.
What popdock provides
--
Choose a date range, the last 7 days by default, and a Rillet product, and it reads Shopify refunds with their successful refund transactions and refunded lines. Each refund is matched to the order's Rillet invoice, and any refund that already has a memo is skipped. Refunds whose money has not gone back yet are listed as pending and not booked. After you confirm, one memo per refund is created and applied to the invoice, capped at the invoice total, and if applying fails the memo is reported as unapplied rather than created again.
Business outcome
---
Shopify refunds reach your Rillet books once each, applied to the right invoice, with nothing double booked.
scenario
-
B2B buyers in Shopify and customers in Rillet drift apart: names are spelled differently, legal suffixes come and go and contact emails change. Working out which company is which, and which exist in only one system, takes a long side by side comparison.
What popdock provides
--
Optionally name one company, and it reads Shopify B2B companies with their contacts and every Rillet customer with their emails. Matching runs in order, external id, exact name, name without legal suffixes, then contact email, and stops at the first rule that fits, listing ambiguous companies with every candidate. You get matched, probable, Shopify only and Rillet only lists, plus email disagreements, with probable matches marked for a person to confirm. It recommends setting the Shopify external id so future runs match exactly, and changes nothing.
Business outcome
---
You know which B2B accounts line up between store and ledger, and which need a person to confirm or fix.
scenario
-
The inventory balance in Rillet should roughly match what is on the shelves in Shopify, but valuing stock means multiplying every tracked item by its cost across locations. Items with no cost and oversold stock distort the total, and differences go unexplained at month end.
What popdock provides
--
Give the balance sheet line and an as-of date, and it values Shopify's tracked on-hand inventory at cost by location and in total. Items with no cost are counted and listed, and oversold items are kept out of the total. It reads the matching Rillet balance sheet line and shows the difference as an amount and a percentage. It states plainly that Shopify gives only today's stock at current cost, keeps different currencies apart, and describes any adjustment without posting it.
Business outcome
---
You see how far stock on hand is from the ledger, with the items behind the gap already listed.
scenario
-
Month end means proving every Shopify order made it into Rillet at the right amount. Matching orders to invoices by number, comparing totals and tax, and catching orders canceled in Shopify but still open in Rillet is tedious work across two exports.
What popdock provides
--
Pick a date range, last month by default, and it reads Shopify orders and the Rillet invoices dated within a week either side. Orders match invoices only by order name, with or without the hash, never on amount or date alone, and totals and tax are compared to within a cent. You get four tables: missing from Rillet, amount mismatches, canceled in Shopify but still open in Rillet, and Rillet invoices with no Shopify order. Mismatched currencies are shown without conversion, and nothing is changed.
Business outcome
---
Month end gets a clear list of Shopify orders to fix in Rillet, instead of a total that does not tie.
scenario
-
The sales tax Shopify collected should match what was posted to your tax liability account in Rillet, but refunds, timing and filings muddy the comparison. Working it out by hand before a filing means adding up order tax, subtracting refunded tax and netting journal lines.
What popdock provides
--
Pick a period and the Rillet tax account, and it confirms the account exists, totals tax on uncancelled Shopify orders, subtracts tax on refunds, and nets the credits and debits posted to that account. For periods of 50 orders or fewer it also breaks the tax down by jurisdiction, and says why when it skips this. Where there is a difference, it lists likely causes, such as refunds booked in another period or orders not yet invoiced in Rillet. Every currency is shown separately, and nothing is posted.
Business outcome
---
You go into a tax filing knowing whether store and ledger agree, and why they differ if not.
scenario
-
For a B2B customer, what they order lives in Shopify and what they owe lives in Rillet. Preparing for a call means checking both, and the gaps are where trouble starts: an outstanding order with no invoice, an invoice overdue on an order Shopify shows as paid, or payment terms that differ.
What popdock provides
--
Name the company and it finds it in Shopify with its locations, payment terms, contacts and recent orders, then finds the matching Rillet customer by external id, name or contact email. From Rillet it reads open and overdue invoices, credit memos, contracts and current ARR. Outstanding orders are compared with Rillet invoices by order name, flagging missing invoices, balances that differ, invoices overdue on orders Shopify shows as paid, and payment terms that disagree. It suggests an obvious next action where there is one, keeps currencies apart and changes nothing.
Business outcome
---
You see a B2B customer's buying and balance together, with every disagreement between store and ledger flagged.
scenario
-
Each successful Stripe charge should become a payment on the matching Rillet invoice, but matching charges to invoices, allowing for partial refunds and avoiding payments already recorded is fiddly work. One double posting or overpayment and the customer's balance is wrong.
What popdock provides
--
Pick a date range and a deposit account, and it confirms the account exists in Rillet, then reads successful Stripe charges linked to invoices, net of anything refunded. Each is matched to a Rillet invoice by exact invoice number. Charges with no Rillet invoice, already paid invoices, overpayments and payments already recorded that day for the same amount are listed and skipped. You preview every payment and nothing is written until you confirm, then each is recorded and read back. If one fails it stops and reports exactly what was recorded.
Business outcome
---
Stripe cash lands on the right Rillet invoices once, with overpayments and duplicates caught before posting.
scenario
-
Invoices raised in Stripe do not always reach Rillet, and recreating them by hand means matching the customer, mapping every line to a Rillet product, carrying service periods across and fitting the line limit. One loose match and you record an invoice twice or against the wrong customer.
What popdock provides
--
Pick a date range and choose whether Rillet should track the receivable or the revenue, and it reads open and paid Stripe invoices and drops any whose number already exists in Rillet, using exact matches only. Customers are matched by email or exact name and products by exact name, and invoices without a clear match are listed as needing a customer or product rather than created. You preview each invoice with its lines and service periods and can confirm a subset. Each is recorded once as an external invoice linked to Stripe, then read back.
Business outcome
---
Missing Stripe invoices reach Rillet with the right customer, products and service periods, and nothing is recorded twice.
scenario
-
Stripe takes its fees before paying out, so they never arrive as bills in Rillet. Booking them means totalling fees across balance transactions per currency, allowing for fee refunds, and making sure the same period is not booked twice.
What popdock provides
--
Pick a period and the fee and clearing accounts, and it checks both accounts exist and that an entry for the same period has not already been booked. It totals Stripe fees per currency from balance transactions, counting fee refunds as reductions, and shows where the fees came from by transaction type. You preview one balanced journal entry per currency, and nothing is booked until you confirm. Each entry is then read back with its ID.
Business outcome
---
Stripe processing fees reach your books every period as balanced entries, and no period is ever booked twice.
scenario
-
MRR in Rillet should match what customers are actually subscribed to in Stripe, but comparing them means converting yearly, weekly and daily prices to monthly values, multiplying by quantity and matching customers across systems. Differences stay hidden until they show up in board numbers.
What popdock provides
--
Pick a month, and optionally a customer name, and it reads Rillet MRR and the active and past due Stripe subscriptions with their items. Each item is converted to a monthly value, metered items are left out and counted, and customers are matched by email, then exact name. You get each customer's Rillet MRR beside their Stripe monthly value, largest difference first with gaps over 1 percent flagged, plus customers found in only one system. It warns when the month is not current, since Stripe shows today, and changes nothing.
Business outcome
---
You catch MRR that does not match real subscriptions before it reaches a board deck or an investor update.
scenario
-
Customers in Stripe and Rillet should line up, but emails change, names are typed differently and duplicates creep in. Without a regular check, payments and invoices end up matched to the wrong customer or to no one at all, and the mistakes surface only when a customer disputes a balance.
What popdock provides
--
Optionally filter by name or creation date, and it reads Stripe customers and every Rillet customer with their emails. Customers are matched by email first, then exact name, and name-only matches are reported separately with both emails side by side, since those are the likeliest to be wrong. Partial names are never treated as matches, only listed as possible ones. You get customers in only one system, duplicates on either side and a count of email matches. It is read-only.
Business outcome
---
Billing and accounting share one clean customer list, with risky name-only matches flagged before they misdirect payments.
scenario
-
Every Stripe invoice should exist in Rillet with the same total, currency and status. Checking means matching numbers across two lists, comparing balances and catching invoices paid in one system but open in the other, which is slow and easy to get wrong.
What popdock provides
--
Pick a date range and it reads non-draft Stripe invoices and the full set of Rillet invoices. Invoices match on exact number, and a probable match by customer, amount and date is offered only when there is no exact one, and never reported as confirmed. For each match it compares total, currency and open balance and flags invoices paid in one system but open in the other. You get missing invoices, disagreements, probable matches to confirm and Rillet invoices with no Stripe counterpart. It changes nothing.
Business outcome
---
You know exactly which Stripe invoices are missing or wrong in Rillet, with uncertain matches left for you to confirm.
scenario
-
A Stripe refund or a lost dispute should be matched by a credit memo in Rillet, but tracing each one back through its charge and invoice is slow. Unbooked refunds overstate revenue, and dispute evidence deadlines slip by while nobody is looking.
What popdock provides
--
Choose a lookback, 30 days by default, and it reads Stripe refunds and disputes and traces each through its charge to the invoice, then to the matching Rillet invoice by exact number and its credit memos. Refunds with no credit memo, or a memo for a different amount, are flagged, as are lost disputes with no memo. Open disputes with evidence due within 7 days come first. Charges not tied to an invoice and invoices missing from Rillet are listed separately, and nothing is booked.
Business outcome
---
Refunds and lost disputes are reflected in your books, and no dispute deadline passes unnoticed.
scenario
-
Chasing overdue invoices works better when you know why a customer has not paid. A failed card, an expired payment method or a past due subscription needs a different response than silence, but that detail sits in Stripe while the overdue balance sits in Rillet.
What popdock provides
--
Optionally filter by customer name and minimum amount, and it totals overdue Rillet invoices per customer and finds each one in Stripe by email, then by name. For each match it reads delinquency, balance, failed charges in the last 90 days with the latest reason, cards expired or expiring within 30 days, and past due subscriptions. You get one row per customer, largest balance first, with a suggested next action such as asking for a new card or retrying the payment. Customers not in Stripe are listed at the end, and nothing is charged or changed.
Business outcome
---
Collections chases the right customers the right way, starting with the largest balances and the clearest fix.
scenario
-
What a client signed for lives in Rillet, while what the team plans and burns lives in Teamwork.com project budgets. Comparing the two means lining up contract terms with budget dates by hand, and a project quietly planned beyond what was sold, or still running after the contract ended, goes unnoticed until the margin is gone.
What popdock provides
--
Name the client and it reads their contracts and contract items in Rillet, then finds the matching Teamwork.com company, by name or by email domain, and reads the budget on each project. Each budget is paired with the contract whose term overlaps it, and hour budgets are converted only when a default rate is set, with a note saying so. It flags budgets above contract value, usage beyond what the client pays for, contracts or budgets with no partner, ended contracts on active projects and term dates more than 30 days apart. Currencies are never converted, and nothing is changed in either system.
Business outcome
---
You see where delivery plans have drifted past the contract before the overrun lands on an invoice nobody can send.
scenario
-
When finance adds customers in Rillet, the delivery team still has to recreate each one as a client company in Teamwork.com before work can be tracked. Doing it by hand means checking every name first, and a slightly different spelling or a missing legal suffix produces a second company for the same client.
What popdock provides
--
Optionally give part of a customer name, and it reads your Rillet customers with their location and billing email, then checks Teamwork.com for each one by name, ignoring case, punctuation and legal suffixes, and then by contact email. Anything that matches, even loosely, is left alone, and anything matching more than one company is listed as ambiguous rather than created. You see the companies to be created, can remove rows, and nothing is written until you confirm. Each new Teamwork.com company id is reported, and a create rejected for an existing name is called out as a missed match.
Business outcome
---
Every Rillet customer has a Teamwork.com client to track work against, with duplicates treated as worse than a gap.
scenario
-
A client can be months behind on Rillet invoices while your team keeps logging hours on their Teamwork.com projects. Finance and delivery rarely look at the same screen, so nobody notices until the unpaid balance has grown by another month of work.
What popdock provides
--
Optionally set a minimum overdue amount and a lookback window, and it totals each customer's overdue Rillet invoices with the oldest due date, then finds their Teamwork.com company and the time logged on its projects in that window. You get one row per customer still receiving work, sorted by what they owe, with hours, billable value and the people involved, plus a short list of overdue customers with no recent time. Clients it cannot match are marked as not found rather than idle. It posts nothing in Teamwork.com and changes nothing in Rillet; you decide who to talk to.
Business outcome
---
You catch clients who are not paying but still getting work, before another month of unbilled effort piles onto the balance.
scenario
-
Billing a project means exporting Teamwork.com time, grouping it by rate, finding the matching Rillet customer and product, and typing the invoice lines in. It is slow, and it is easy to bill the same period twice or miss a rate that was never set.
What popdock provides
--
Name the project, the period and optionally the product, and it reads the billable Teamwork.com time grouped by rate, then matches the client to a Rillet customer by name or company email domain and says which rule matched. Before drafting, it looks for existing Rillet invoice lines that overlap the period or name the project and asks whether to continue. You see the draft lines beside the Teamwork.com total, zero-rate time is set aside for you, and the invoice is created in Rillet only after you confirm. It never creates customers or products, and an error is shown rather than retried with changed values.
Business outcome
---
Project time becomes a correct Rillet invoice in one pass, with a double billing check before anything is created.
scenario
-
Renewal conversations go badly when nobody checked how delivery is going first. The contract end date is in Rillet, but late milestones, open risks and unhappy project updates are scattered across Teamwork.com, so a renewal at risk looks safe until the client says no.
What popdock provides
--
Set how many days ahead to look, and it lists the active Rillet contracts ending in that window with each customer's overdue balance. For each client it finds the active Teamwork.com projects and reads their health score, latest update, late milestones and open risks. Each renewal is rated High, Medium or Low by stated rules, such as any late milestone or overdue invoice making it High, and every High row gets one sentence of reasoning. Clients not tracked in Teamwork.com are rated on the Rillet side alone, and nothing is changed in either system.
Business outcome
---
Account teams walk into renewals knowing which ones are at risk and why, with time left to fix delivery first.
scenario
-
Client lists drift apart when delivery adds companies in Teamwork.com and finance adds customers in Rillet. A client with active projects but no Rillet customer may never be invoiced, and checking the two lists against each other by eye misses near matches and different spellings.
What popdock provides
--
Optionally narrow by part of a company name, and it reads the Teamwork.com companies and the Rillet customers with their emails. Names are matched ignoring case, punctuation and legal suffixes, then unmatched companies are tried by contact email or shared company domain, never a public mail domain and never on city alone. You get four sections, matched with any address differences, Teamwork.com only with project-holding companies first, Rillet only, and ambiguous, plus counts. Your own site company is left out and noted, and nothing is changed.
Business outcome
---
You find clients that are being served but never billed, and fix the gaps before month end.
scenario
-
Knowing whether a client is worth keeping means setting invoiced revenue in Rillet against the cost of the hours logged in Teamwork.com. Pulling both, matching the client and netting out credits takes an afternoon, and people with no cost rate quietly make the margin look better than it is.
What popdock provides
--
Name the client and a period, and it reads every Teamwork.com project's hours, cost and billable value, then matches the client to a Rillet customer by name or company email domain and totals invoice lines in the period, less credit memos. The report shows margin and margin percent, revenue per hour and billable value not yet invoiced. It names anyone with hours but no cost rate and says the margin is overstated by their time. Revenue is stated as invoiced, not recognized, currencies are never converted and nothing is changed.
Business outcome
---
You get an honest margin for each client, with its blind spots named, before deciding on rates or renewals.
scenario
-
Billable hours logged in Teamwork.com do not always make it onto a Rillet invoice. There is no link between a time entry and an invoice line, so checking means adding up time per project, adding up invoiced amounts for the same period, and guessing where the gap came from.
What popdock provides
--
Name the client and a period, and it totals billable Teamwork.com time per project, noting unverified entries, then finds the Rillet customer by name or company email domain and totals the invoice lines for that period net of credits. If time exceeds invoicing by more than 5 percent it calls out probable unbilled time and lists the ten largest entries. If Rillet is higher it checks for a fixed-fee or retainer contract. It says plainly that the comparison is by amount and period only, flags time with missing billable rates and changes nothing.
Business outcome
---
Unbilled work is found and sized while it can still go on an invoice, not written off at year end.
scenario
-
Every WooCommerce sale that is paid still has to be recorded as a payment on its Rillet invoice. Matching orders to invoices by number, checking the amount due and posting each payment by hand is repetitive, and posting one twice or against an already paid invoice throws receivables off.
What popdock provides
--
Give a date range and the Rillet account to post to, and it reads the WooCommerce orders paid in that range and finds each one's Rillet invoice by order number or id. Orders are sorted into ready, no invoice, already paid, over the amount due and currency mismatch, and any order whose invoice already has a payment of the same date and amount is held back as possibly recorded. The account is checked as active, you see amounts due before and after, and nothing is posted until you confirm. Refunds are left for credit memos rather than netted against payments.
Business outcome
---
Online payments land on the right Rillet invoices once each, with possible repeats held back for you to check.
scenario
-
When WooCommerce sales are not flowing into Rillet, someone has to find the orders with no invoice and key each one in with the right customer, net amount and tax. It is tedious, and a second pass over the same dates easily creates duplicate invoices.
What popdock provides
--
Give a date range and the Rillet product to book against, and it reads the WooCommerce orders that count as sales, totals each one's item tax, and keeps only those with no Rillet invoice under the same order number or id. Customers are matched by email, or to a fallback customer you name, and orders it cannot place are listed rather than created. You review net, tax and total for each invoice and nothing is created until you confirm. Rillet invoices are re-read just before creating so a repeat run does not duplicate, and WooCommerce is never changed.
Business outcome
---
Missing online sales reach Rillet as receivables with the right customer and tax, without duplicate invoices from a second run.
scenario
-
A refund issued in WooCommerce still needs a Rillet credit memo applied to the original invoice, or receivables stay overstated. Finding the invoice, checking whether the refund was already booked and applying the right amount by hand is easy to get wrong, especially for refunds paid back outside the gateway.
What popdock provides
--
Give a date range and the Rillet product to credit, and it reads each WooCommerce refund with its lines, finds the order's Rillet invoice and skips any refund that already has a memo numbered for it. You see every refund with its reason and invoice balance, with manual refunds flagged and orders with no invoice listed apart, and nothing is created until you confirm. Each memo is then created and applied to its invoice, capped at the amount due, and left unapplied with a note when the invoice was already paid. If applying fails, the memo is reported as unapplied and never created twice.
Business outcome
---
Every WooCommerce refund is credited against the right Rillet invoice once, so receivables match what customers actually owe.
scenario
-
Customers who buy in WooCommerce and customers billed in Rillet are rarely recorded the same way. One system has the email, the other the company name, and locations drift, so working out who exists where means scrolling two lists and guessing at near matches.
What popdock provides
--
Optionally narrow by part of an email, and it reads paying WooCommerce customers and every Rillet customer with their emails. It matches by email first, then by company, then by full name, stopping at the first rule that fits and listing anyone matching several Rillet customers as ambiguous. You get exact matches, probable matches that need a person to confirm, customers in only one system and matched customers whose country or state disagree. It changes nothing, and explains that guest checkouts will not appear.
Business outcome
---
You know which online buyers are set up in your ledger and which need attention, without guessing at matches.
scenario
-
Month end means proving that every WooCommerce sale reached Rillet at the right amount. Checking order numbers against invoice numbers in two exports is slow, and canceled orders that were still invoiced are the kind of error that only shows up when a customer disputes a bill.
What popdock provides
--
Give a date range, defaulting to last month, and it reads WooCommerce orders and separates real sales from pending, failed and canceled ones. Rillet invoices are read with a seven day margin either side and matched on order number, then order id, never on amount or date alone. You get a summary and tables for orders missing from Rillet, amounts that differ by more than a cent, non-sales that were invoiced, and Rillet invoices with no order, noted as possibly from another channel. Currencies are not converted and nothing is changed.
Business outcome
---
You close the month knowing every online sale is booked once at the right amount, with exceptions listed for follow-up.
scenario
-
Refunds are easy to issue in WooCommerce and easy to forget in Rillet. Without a matching credit memo applied to the order's invoice, receivables are overstated, and refunds paid back by hand outside the gateway need the cash side checked as well.
What popdock provides
--
Give a date range and it reads every WooCommerce refund, then Rillet credit memos from a widened window and the invoices for each order. A memo numbered for the refund is an exact match, and a memo on the order's invoice for the same amount is a probable one. You get refunds not credited, with whether the order was ever invoiced, amounts that differ, memos not applied to their invoice, refunds made outside the payment gateway and stray memos. Nothing is created or applied; it points you to the job that books missing credits.
Business outcome
---
Refunds and credits agree at month end, and manual refunds are flagged for a cash check.
scenario
-
Before a sales tax filing, the tax WooCommerce collected should agree with what landed in the Rillet tax account. Totalling order line tax, taking off refunded tax and netting journal lines by hand takes time, and the difference rarely explains itself.
What popdock provides
--
Give a period and your Rillet tax account, and it confirms the account exists, sums item tax on WooCommerce sale orders and the tax on refund lines, then nets the credits and debits posted to that account in Rillet. A table by currency shows collected, refunded, net and posted tax and the difference. When they disagree it lists likely causes, such as shipping tax not in the WooCommerce figure, refunds in another period, orders not yet invoiced or filings posted to the same account. It never posts an adjustment; it says what one would be.
Business outcome
---
You file sales tax with the WooCommerce and Rillet figures reconciled and any gap explained.
scenario
-
When a customer calls about their account, the orders and refunds are in WooCommerce and the invoices, payments and credits are in Rillet. Piecing together one picture by email, and spotting where the two disagree, takes several screens and a lot of matching by hand.
What popdock provides
--
Give the customer's email and a lookback window, and it reads their WooCommerce record, orders and refunds, then finds them in Rillet by email, or by company or name, and reads their invoices, credit memos and payments. It flags sales with no invoice, paid orders whose invoice is still open, totals that differ, refunds with no memo and canceled orders with an open invoice. You get both sides summarized, the disagreements as a table and the obvious next step if there is one. Guest buyers are handled, and nothing is changed.
Business outcome
---
You answer a customer's account question from one combined view, with every mismatch between store and ledger already found.
scenario
-
Customers billed in Rillet should be on your Drip list so they get customer messaging, but the two drift apart. Adding the missing emails by hand is slow, and because Drip updates anyone who already exists, a careless import can quietly re-subscribe someone who opted out.
What popdock provides
--
Choose a tag and optionally an email type, and it reads Rillet customer emails, drops blanks, malformed addresses and duplicates, and checks each one in Drip. Only emails with no Drip record at all are treated as gaps; anyone unsubscribed is left alone. You review the list with names, countries and the tag, can remove rows, and nothing is written until you confirm. Each confirmed email is added once and then checked in Drip. Rillet is never written to.
Business outcome
---
Every Rillet customer is on your Drip list with the right tag, and no one who unsubscribed is brought back.
scenario
-
A drop in a customer's ARR in Rillet is often the first sign they are drifting away, and a silent inbox in Drip can confirm it. Linking the two means comparing ARR month over month, finding each declining customer's emails and checking their Drip engagement one by one.
What popdock provides
--
Choose a month, or let it use the latest, and it compares each customer's Rillet ARR with the month before, keeping those that fell, dropped to zero or disappeared. It attaches their emails and reads Drip status, lead score, lifetime value and tags. Nothing is changed in either system. You get a table sorted by ARR lost, with currencies kept separate, and a note on any customer with no active Drip subscriber. If a month has no ARR rows it stops rather than treating everyone as churned.
Business outcome
---
You spot at-risk customers early and know which of them marketing can still reach.
scenario
-
Collections and marketing both want to know whether overdue Rillet customers can still be reached by email. Finding out means totalling overdue invoices per customer, pulling their email addresses, and checking each against Drip for status and active campaigns.
What popdock provides
--
Set a minimum amount and it reads Rillet invoices once, keeps the overdue ones, totals them per customer and currency, and attaches every customer email. Each email is checked in Drip for status, lead score, tags and active campaigns. Nothing is changed, and it does not suggest pausing or unsubscribing anyone. You get a table sorted by amount due, with oldest due date, and customers whose emails are all unsubscribed or missing flagged as unreachable. Customers with no email on file are listed rather than dropped.
Business outcome
---
You see which overdue Rillet customers email can still reach before deciding how to follow up.
scenario
-
When one person is both a billed customer in Rillet and a subscriber in Drip, nobody has the full picture. Finance sees contracts and overdue invoices, marketing sees tags and campaigns, and spotting a problem such as an overdue customer who has unsubscribed takes both screens.
What popdock provides
--
Give an email address and it finds every Rillet customer that uses it, then reads their contracts, open and overdue invoices and the last two months of ARR. It reads the Drip subscriber for status, tags, lead score, lifetime value and consent, plus their campaigns. Records are matched on email only and nothing is written. You get a billing section, a marketing section and a line of observations, and if the email exists in only one system it says so plainly.
Business outcome
---
Finance and marketing share one view of a customer's billing position and email engagement.
scenario
-
A renewal email series only works if it reaches customers before their contracts end. Building that list means finding Rillet contracts ending soon, pulling each customer's emails, and checking Drip so you do not enrol people who unsubscribed or who are already in the campaign.
What popdock provides
--
Name a Drip campaign and a window in days, and it finds active Rillet contracts ending in that window and attaches each customer's emails. Unsubscribed Drip people and anyone already in the campaign are skipped. You review customer, contract, end date and email, and the confirmation says which people are new to Drip and will be created. Nothing is written until you confirm. It warns if the campaign is inactive, reports enrolled, skipped and failed, and never writes to Rillet.
Business outcome
---
Renewal messaging reaches customers ahead of their contract end date, without enrolling anyone who opted out.
scenario
-
Your most engaged Drip subscribers may already be paying customers in Rillet, or they may be real prospects nobody has contacted. Telling them apart means checking each email against Rillet customer records, and a prospect using a different address from their company is easy to misjudge.
What popdock provides
--
Set a minimum lead score and it reads active Drip subscribers at or above it, then compares their emails with every Rillet customer email. Subscribers who are not customers are listed by lead score with value, tags and created date. Nothing is changed in either system. As a hint only, it flags when an email domain matches an existing Rillet customer, ignoring free mail domains, so you can spot someone from a company you already bill.
Business outcome
---
Sales gets a ranked list of engaged prospects who are not yet customers, with likely existing accounts flagged.
scenario
-
Your billing customers live in Rillet and your email audience lives in Drip, and nothing tells you when the two drift apart. Finding the gap means exporting every customer email, looking each one up in Drip, and remembering that a different capital letter is not a different person. Customers you invoice but never email slip through unnoticed.
What popdock provides
--
Nothing is changed in either system: this job only reads and reports. Optionally name an email type, and it reads every customer email address in Rillet, removes blanks and duplicates, and checks each one against your Drip subscribers by trimmed, lower-cased email, never by name. You get a table of the Rillet customers Drip does not have, with customer name, ID, email type and country, a second table of those who exist in Drip but are unsubscribed, and counts for checked, active, unsubscribed and missing.
Business outcome
---
You see exactly which billing customers your Drip email cannot reach, without touching a record in Rillet or Drip.
scenario
-
When a customer falls behind on payment in Rillet, your Drip emails keep treating them like everyone else, promotions and all. Flagging them by hand means pulling overdue invoices, matching each customer to their email addresses, and tagging each subscriber in Drip one at a time. It rarely gets done, so collections and marketing send mixed messages.
What popdock provides
--
Nothing is tagged until you approve the list. Set how many days past due counts as overdue and the tag to use, and it reads your Rillet invoices for unpaid balances past their due date, totals the amount due per currency and finds the oldest due date for each customer. It matches every customer email to Drip, skips anyone already tagged or not in Drip, and shows you the name, email, amount due and due date first. After you confirm it applies the tag in Drip, and Rillet is never written to.
Business outcome
---
Customers with overdue Rillet invoices carry a Drip tag your automations can act on, applied only to the people you approved.
scenario
-
Re-keying an approved Ramp bill into Rillet means copying the vendor, dates, amounts and expense lines across by hand. It is easy to book the same bill twice, code a line to the wrong account, or end up with line totals that do not add up to the bill amount.
What popdock provides
--
Give the Ramp invoice number, and optionally the vendor and the Rillet account code for the expense lines. It reads the approved Ramp bill and its lines, matches the vendor to an existing Rillet vendor, confirms the account is active, and checks Rillet for a bill with the same number. You see the exact vendor, dates, line amounts, account and currency, and nothing is booked until you say yes. It then reads the bill back from Rillet. Ramp is never changed.
Business outcome
---
Approved Ramp bills are booked in Rillet once, on a valid account, with line totals that match the bill.
scenario
-
Ramp spend is coded to general ledger accounts, and those codes have to exist in the Rillet chart of accounts. When a code is missing, renamed or inactive, nobody finds out until a sync fails and someone has to compare two account lists by hand.
What popdock provides
--
Ask for a comparison, and optionally limit it to codes containing some text or include inactive Ramp accounts. It reads the Ramp GL accounts and the Rillet chart of accounts, then matches each Ramp code to a Rillet account code. It lists Ramp codes missing from Rillet with a candidate account of the same name, matched codes whose names differ, and matched codes where the Rillet account is not active. Codes that appear twice on one side are flagged, not matched. Nothing is changed in either system.
Business outcome
---
Account code gaps between Ramp and Rillet are found and listed before they break a sync, with nothing changed.
scenario
-
When a vendor already exists in Ramp, setting it up again in Rillet means retyping the name and email and finding an address Ramp does not hold. Skip the search and you create a duplicate vendor, and leave out a required address field and the vendor will not save.
What popdock provides
--
Give the Ramp vendor name, and the address details if you have them. It finds the vendor in Ramp, picks up the default contact email, and checks Rillet for the same name or email. If several Ramp vendors match, or Rillet already has the vendor, it stops and tells you. It asks for any missing required address field, shows the exact values, and creates the vendor only after you say yes. It then confirms the vendor appears in Rillet. Ramp is never changed.
Business outcome
---
Ramp vendors are created in Rillet once, with the required address details and no duplicates to clean up.
scenario
-
A bill paid through Ramp stays open in Rillet until someone records the payment there. Checking each paid bill against Rillet by hand is slow, so missing payments and amount differences go unnoticed until the AP ledger is off.
What popdock provides
--
Give a due-date range. It finds the Ramp bills in that range that Ramp shows as paid, matches each to its Rillet bill by invoice number, and looks for a payment in Rillet within 30 days after the end of the range. It reports bills paid in Ramp with no Rillet payment, payments whose amounts differ, bills missing from Rillet, and Rillet payments Ramp does not show as paid. Amounts are compared only in the same currency. It lists the exceptions and fixes nothing.
Business outcome
---
Unrecorded and mismatched bill payments are listed before the AP ledger drifts, with nothing changed in either system.
scenario
-
Matching Ramp bills to Rillet bills by hand means comparing invoice numbers and totals across two screens. Bills that were never booked, or booked for a different amount, slip through and payables are misstated at close.
What popdock provides
--
Give a due-date range. It reads the Ramp bills in that range, skipping rejected and deleted ones, then reads the Rillet bills and lines and totals each Rillet bill. Bills are matched by invoice number, and a close match on vendor, total and due date is marked Probable. The report shows Matched, Amount differs, Not in Rillet and Only in Rillet, problems first and largest difference first, with the total value not in Rillet. Amounts are compared only in the same currency, and nothing is changed.
Business outcome
---
Unbooked bills and amount differences are found before close, with the value at risk totalled and nothing changed.
scenario
-
Employee reimbursements approved in Ramp are not always booked in Rillet. Rillet records the employee as a vendor, so matching by name, amount and date means searching across systems by hand, and unbooked reimbursements go unnoticed.
What popdock provides
--
Give a date range. It reads the Ramp reimbursements in that range and the Rillet reimbursements and items, then maps each Rillet vendor to a name and email. A reimbursement is matched when the employee name or email agrees, the amount is equal in the same currency, and the dates are within 5 days. The report shows Matched, Not in Rillet and Amount differs, plus Rillet reimbursements with no Ramp counterpart. If no vendor matches an employee it says so. Nothing is added to either system.
Business outcome
---
Unbooked and differing reimbursements are listed with a reason for each, so none are missed, and nothing is changed.
scenario
-
Someone compares the Ramp vendor list to the Rillet vendor list by eye. Names differ by suffix or punctuation, and a vendor that exists in only one system goes unnoticed until a bill fails to post.
What popdock provides
--
Ask for the comparison, optionally limited to names containing some text, and optionally including inactive Ramp vendors. It reads the vendors in both Ramp and Rillet and matches them by name after ignoring case, punctuation and suffixes such as Inc, LLC and Ltd. The report has four lists: in Ramp only with year to date spend, in Rillet only, matched with any country differences, and ambiguous. A name that fits several Rillet vendors is never guessed. It says so if a result is partial. Nothing is changed.
Business outcome
---
Vendors missing from either system are found before a bill fails to post, with the biggest Ramp spend first.
scenario
-
A bill paid through Ramp stays open in Rillet until someone records the payment, with the amount and date typed by hand. Record it twice, or against a bill whose amount differs, and the payables ledger no longer agrees with the bank.
What popdock provides
--
Give the Ramp invoice number, and optionally the Rillet account code and payment date. It confirms Ramp shows the bill as paid, finds the matching Rillet bill, and checks whether a payment of the same amount is already recorded. It stops if the bill is not paid, is missing from Rillet, is already paid, or the amounts differ. You see the bill, amount, currency, date and account, and nothing is recorded until you say yes. It then reads the payment back from Rillet. Ramp is never changed.
Business outcome
---
Paid Ramp bills are closed in Rillet once, with the right amount and date and no double payments.
scenario
-
To confirm that an invoice carries the right tax, an analyst opens the invoice in Rillet and the matching transaction in Avalara AvaTax side by side. A mismatch is easy to miss, or to chase in the wrong record.
What popdock provides
--
Name an invoice and it finds the Rillet invoice and the AvaTax transaction for it. It compares the tax, the taxable amount and the date and reports each difference. It stops when nothing matches or several records match, and refuses to compare amounts in different currencies. Nothing is written to Rillet or AvaTax.
Business outcome
---
Tax differences between a Rillet invoice and AvaTax are spotted in one answer, with nothing changed in either system.
scenario
-
Credit memos in Rillet should reverse tax in Avalara AvaTax too. When the return is missing, tax stays overstated on the filing, and spotting it means matching memos to returns by hand.
What popdock provides
--
It matches Rillet credit memos to return transactions in Avalara AvaTax and flags memos with no return and tax that differs. Fuzzy matches are labelled as likely, and amounts are compared as absolute values. If AvaTax holds no returns it falls back to showing the credit memos alone. Nothing is written to either system.
Business outcome
---
Credit memos with no matching AvaTax return are found before filing, with nothing changed in either system.
scenario
-
The same customer is kept in the Rillet ledger and in Avalara AvaTax. Address drift between them leads to wrong tax, and it is usually found only after the fact.
What popdock provides
--
Name a customer and it finds the customer in Rillet and in Avalara AvaTax, compares the address fields and shows recent activity in each. It stops when several records match and flags matches it had to guess. Suggested changes are listed but never made, and nothing is written to either system.
Business outcome
---
Customer address drift between Rillet and AvaTax is found before it causes wrong tax, with changes left to you.
scenario
-
Vendor details are kept in both the Rillet ledger and Avalara AvaTax. A mismatched tax ID or address causes use tax and 1099 problems later, when fixing it is slow and urgent.
What popdock provides
--
Name a vendor and it finds the vendor in Rillet and in Avalara AvaTax, compares identity, tax ID and address and shows recent bill activity. Tax IDs are masked, empty fields are reported as Missing and the lookup stops when several records match. Nothing is edited in either system.
Business outcome
---
Vendor mismatches that cause use tax and 1099 problems are found early, with tax IDs masked and nothing edited.
scenario
-
Invoices raised outside the tax engine slip through with hand-entered tax. Finding them means comparing a Rillet invoice list with Avalara AvaTax by eye.
What popdock provides
--
Give a date range and it lists taxed Rillet invoices that have no AvaTax transaction and flags matched ones that are not yet committed. It runs one AvaTax query for the whole window instead of one per invoice, and warns when AvaTax returns nothing rather than listing everything as missing. Nothing is written to either system.
Business outcome
---
Taxed invoices with no AvaTax transaction are found in one pass, with nothing changed in either system.
scenario
-
At month end an accountant exports invoices from the Rillet ledger and transactions from Avalara AvaTax and compares totals in a spreadsheet. Gaps between the two are found late.
What popdock provides
--
Give a date range and it totals tax and amounts for that range in Rillet and in AvaTax, then lists the unmatched and mismatched invoices behind any gap. Matching is on invoice number to transaction code, and it warns when that is unreliable. It caps long lists, validates the date range and never writes to either system.
Business outcome
---
The invoices behind a period gap between Rillet and AvaTax are listed in one answer, with nothing changed in either system.
scenario
-
Subscriptions in the billing system and contracts in the accounting system are kept in step by hand, so cancellations, renewals and dates fall out of line. Comparing them means reading Chargebee subscriptions, finding the same customer in Rillet and matching each pair yourself.
What popdock provides
--
Give a Chargebee customer id and it reads their subscriptions from Chargebee, finds the same customer in Rillet by email or name and reads their contracts and contract lines. It pairs each subscription with a contract by start date and currency, then reports pairs with status, date or value differences, subscriptions with no contract and contracts with no subscription. Guessed pairings are labelled as guesses and value checks are skipped across currencies. It only reads and suggests fixes in words, so nothing in either system is changed.
Business outcome
---
Operations sees which subscriptions and contracts disagree and which side to fix, without anything being written to Rillet.
scenario
-
Recurring revenue reported from billing and from accounting drifts apart, and nobody can say which customers explain the gap. Comparing means summing Chargebee subscription MRR by hand, then finding the same customer in Rillet and reading its revenue figures.
What popdock provides
--
Give a Chargebee customer id and optionally a month, and it sums the MRR of their active subscriptions in Chargebee, showing trial and non renewing ones separately. It finds the customer in Rillet and reads Rillet's MRR waterfall for that month, or the latest month available. You get Chargebee MRR by subscription and in total, the Rillet figure and the difference with a likely reason, such as a cancelled subscription, a trial, a missing contract or a currency difference. It never writes to Rillet and never subtracts across currencies.
Business outcome
---
Leadership can see which customers explain the gap between billing and accounting MRR, and the likely reason for each.
scenario
-
Setting up a Chargebee customer in Rillet means retyping their details, which risks duplicates and typos. Someone has to check Rillet for an existing record under a different spelling before creating anything, then confirm the new one exists.
What popdock provides
--
Give a Chargebee customer id, and optionally payment terms, and it reads the customer from Chargebee. It checks Rillet for the same email and for an exact name match, and if it finds one it shows it and stops without creating anything. Otherwise it shows exactly what will be created and tells you the email must be added in Rillet afterwards. Nothing is created until you say yes, and then it creates the customer once and reads Rillet again to confirm it, without retrying on failure.
Business outcome
---
New customers reach Rillet once, with the details you approved and no duplicates, and nothing is written to Chargebee.
scenario
-
Finance eyeballs the Chargebee customer list against the Rillet customer list, and name variants and shared emails let customers slip through unnoticed. Rillet cannot filter its customers, so the comparison is done by hand.
What popdock provides
--
Give a number of customers to look at, or use 25, and optionally a company name filter, and it reads those Chargebee customers and all Rillet customers and their emails. It matches on email first, then on an exact company or full name match against the Rillet name or invoicing name, and labels each result as matched by email, matched by name only or no match. You get a table with the Rillet customer id and match basis, the unmatched customers and any Rillet customer matched by more than one Chargebee customer. It never writes to Rillet.
Business outcome
---
Finance sees which Chargebee customers have no Rillet record and which matches are weaker, with duplicates flagged.
scenario
-
Credit notes issued in Chargebee may never become credit memos in Rillet, leaving revenue and receivables overstated. Checking means pulling both sets for a customer and matching them by number, total and date yourself.
What popdock provides
--
Give a Chargebee customer id, and optionally a start date, and it reads their credit notes from Chargebee and finds the customer in Rillet by email. It reads the Rillet credit memos from the same date and matches by credit memo number, then by total and a date within three days, checking the linked invoice where it can. You get credit notes missing in Rillet, credit memos missing in Chargebee and matched pairs with any difference, ending with the net amount not reflected in Rillet. Currency mismatches are listed separately and no Rillet credit memo is created or changed.
Business outcome
---
Finance sees exactly which credit notes are not reflected in Rillet and the net amount involved.
scenario
-
Accountants compare billing invoices with ledger invoices line by line, and missing or mismatched ones surface only at month end close. Rillet cannot filter its invoices, so every comparison is done by eye.
What popdock provides
--
Give a Chargebee customer id, and optionally a start date, and it reads their invoices from Chargebee and finds the customer in Rillet by email, falling back to company name. It reads the Rillet invoices for that customer and matches by invoice number, then purchase order number, then by date and total. You get invoices in Chargebee only, in Rillet only and in both with a difference, ending with counts and the total gap in amount due. It refuses to compare amounts across currencies and points out when a total differs by exactly 100 times. It never writes to Rillet.
Business outcome
---
Accountants see every missing or differing invoice between Chargebee and Rillet before month end close, not during it.
scenario
-
Cash received in Chargebee is not always recorded as an invoice payment in Rillet, and finding the gap by hand is slow and error prone. Rillet cannot filter its payments, so each one must be traced through the customer's invoices.
What popdock provides
--
Give a Chargebee customer id, and optionally a start date, and it reads their successful payments from Chargebee. It finds the customer in Rillet by email, reads their invoices and then the payments recorded against those invoices. It matches payments with the same amount and currency within three days, using each Rillet payment only once and flagging same amount matches as ambiguous. You get Chargebee payments with no Rillet payment, which are unrecorded cash, Rillet payments with no Chargebee payment and matched pairs, with the unrecorded total per currency. It never adds or updates Rillet payments.
Business outcome
---
Finance finds unrecorded cash in Rillet and its total per currency, without any payment being added automatically.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.