ERP
Sage Intacct
Connect your AI to Sage Intacct
Controllers, AP teams, and CFOs run every financial decision through Sage Intacct, but the answers they need span entities, dimensions, and periods that Intacct's native reporting treats as separate queries. AI can surface those answers in seconds, but only if it respects the entity boundaries, dimension structures, and allows controlled actions.
Why it matters
Capabilities that matter most for Sage Intacct
01
Every entity in one connection
Connect at the top-level company and work across every Intacct entity, then compare them side by side in one comparison list.
02
Matrix reports by fiscal period
Roll up any Intacct list by month or fiscal period across entities and dimensions, without building a new custom report.
03
Intacct beside your other systems
Join Intacct with CRM, billing or payroll lists so close and reconciliation questions get one answer.
03
Governed AI for finance
MCP tools respect entity boundaries and per-user, per-team security, and only change records through approved actions.
Use cases
Example AI Use Cases for Sage Intacct
scenario
-
Projects often start life in Asana and never get set up in Sage Intacct, so the time and costs for them have nowhere to go. Finding which active projects are missing means comparing two long lists by eye.
What popdock provides
--
It reads your active Asana projects, optionally for one team, and every project in Sage Intacct, and lists the Asana projects with no Intacct project of the same name. Names that are close but not equal are shown separately for you to decide rather than treated as missing. Once you confirm the list, it creates each project in Intacct with the category you choose and the Asana start and due dates, then reads it back to confirm it exists. It never edits an existing project.
Business outcome
---
Every active project can be costed in Sage Intacct, without duplicates and without retyping project details.
scenario
-
The people doing the work on a project in Asana are not always the people set up as resources on it in Sage Intacct. Anyone missing in Intacct cannot have their time costed to the project, and leavers can stay assigned long after they have gone.
What popdock provides
--
Name the project and it reads its members and allocations in Asana and its resources in Sage Intacct, then matches people by name, handling Last, First against First Last. It lists who is on both sides with their access, allocation dates and labor rate, who is in Asana only and so cannot be costed, and who is in Intacct only, calling out anyone inactive or past their end date. It never pairs two different names on a guess, and it changes nothing.
Business outcome
---
Project staffing matches across both systems, so every hour worked can be costed and leavers are cleared out.
scenario
-
When a project's tasks are kept in both Asana and Sage Intacct, they drift: a task finished in one is still open in the other, dates move on one side only, and new tasks are added to just one system. Spotting the differences by hand is tedious.
What popdock provides
--
Name the project and it reads its tasks from Asana and from Sage Intacct and matches them by exact name. It reports tasks that disagree on completion or on due dates beyond a tolerance you set, plus tasks that exist on only one side, with counts for each. A task with no date is treated as unset rather than as a mismatch, and a side with no tasks is reported once rather than as a wall of differences. It only reads.
Business outcome
---
Project plans stay in step across both systems, so billing and reporting reflect the work that is really done.
scenario
-
Time is tracked against tasks in Asana, but the hours that are costed and billed come from Sage Intacct timesheets. Checking that the two agree for a project means totalling each person's time in both systems and lining the names up.
What popdock provides
--
Name the project and a date range, the last 30 days by default, and it totals each person's Asana tracked time and their Intacct timesheet hours, including billable hours. You get one row per person with the difference, largest first, plus anyone who appears on only one side. Differences under a quarter of an hour are treated as rounding, not discrepancies, and similar names are never guessed. It only reads both systems.
Business outcome
---
Project hours agree between delivery and finance before they are billed, with the real gaps easy to see.
scenario
-
Overdue invoices live in Sage Intacct, while the collections work is planned in Asana. Copying each one into a task with the customer's details is repetitive, and it is easy to duplicate a task someone already has.
What popdock provides
--
Set how many days overdue counts, 30 by default, and name the Asana project, and it finds the overdue Sage Intacct invoices and adds each customer's email and rep. Invoices that already have an open task in the project are skipped. You see the tasks it would create and nothing is created until you confirm. It creates at most 25 per run, largest amounts first, each with the invoice, amount, due date and contact details in its notes. Intacct is never changed.
Business outcome
---
Collections work starts from a complete, duplicate-free task list, so overdue cash is chased sooner.
scenario
-
Contract value, actuals and the customer's unpaid invoices are tracked in Sage Intacct, but the team running the project lives in Asana and seldom sees them. Sharing the numbers means copying them over by hand.
What popdock provides
--
Name the project and it reads the contract amount, budgeted billing, actual amount and percent complete from Sage Intacct, plus the customer's overdue invoices. It drafts an Asana status update with one figure per line and proposes a status, for example at risk when actuals pass 90 percent of the contract before the work is 90 percent done. It notes that the invoices belong to the customer, not necessarily the project. You confirm the draft before it is posted, and Intacct is never changed.
Business outcome
---
Project teams see the financial picture in Asana, so cost and collection risks are acted on early.
scenario
-
Projects are tracked in Asana for delivery and in Sage Intacct for finance, and the two lists drift apart. Projects finished on one side stay open on the other, dates and owners disagree, and some projects never reach one of the systems.
What popdock provides
--
It reads your Asana projects, optionally narrowed by name and team, and your Sage Intacct projects, and matches them by exact name. You get four lists: projects that disagree on completion, start date, end date or owner, with both values side by side, projects only in Asana, projects only in Intacct, and names that matched more than once. Dates are compared as dates, and an unset date is not counted as a mismatch. It only reads both systems.
Business outcome
---
Delivery and finance work from the same project list, so nothing is billed late or left open by mistake.
scenario
-
Each Bloomerang fund points at a Sage Intacct account through its GL class, but values get typed with stray spaces, accounts go inactive, and some are closed to direct posting. Those problems only appear when a journal entry fails, and checking fund by fund takes an afternoon.
What popdock provides
--
Check every active fund or those matching a name, and it looks up each GL class as a Sage Intacct account, retrying once with formatting cleaned up and checking projects if no account matches. Findings are ranked blocking, warning or note: blank classes, missing or inactive accounts and no direct posting block posting, while formatting mismatches, balance sheet accounts and required department or location dimensions are warnings. Each comes with the fix and the system to change it in. It never matches by title or partial number, and it recommends fixes without making them.
Business outcome
---
Fund to account mapping is clean before gifts are booked, so journal entries post the first time.
scenario
-
Boards ask how fundraising is tracking against budget, but the budget sits in Sage Intacct, gifts in Bloomerang and booked revenue in the general ledger. Lining them up by account, while keeping pledges apart from cash received, is a monthly spreadsheet chore.
What popdock provides
--
Name the Sage Intacct budget and a date range, and it maps active Bloomerang funds to their revenue accounts, then reads the budget to date and the full budget for each account. Money raised in Bloomerang is totalled apart from new pledges and open pledge balances, and booked revenue is read from the ledger on an accrual basis. You get one row per account with percent of budget to date, the biggest shortfall and overrun, accounts where raised and booked differ by more than five percent, and campaigns ending in the period. Unbudgeted and unmapped items are flagged, and nothing is changed.
Business outcome
---
Leaders see fundraising against budget by account, with pledges separated from cash, ready for a board update.
scenario
-
Each day's Bloomerang gifts need to become journal entries in Sage Intacct by fund, but refunds, pledges and processor fees complicate the totals. Done by hand, gifts get booked twice, or to an account that is inactive or will not accept the posting.
What popdock provides
--
Give the gift date, the debit account and optionally a journal, and it totals the day's gifts by fund, leaving out refunds and pledges and setting aside gifts whose designations do not add up. Each account is checked in Sage Intacct, and required department or location IDs are asked for, not guessed. It skips any fund already booked under its reference number, or whose account already shows similar credits that day, and asks how to treat processing fees. After you confirm the plan it creates one draft entry per fund and reads each back.
Business outcome
---
Daily gifts are booked to Sage Intacct by fund as draft entries, without duplicates or failed postings.
scenario
-
Fund totals in Bloomerang and revenue in Sage Intacct drift apart for many reasons: timing, refunds not reversed, pledges booked differently, gifts coded to the wrong account. Explaining each variance means pulling both sides by fund and reading ledger detail line by line.
What popdock provides
--
Give a period, and optionally one fund, and it maps each fund to its Sage Intacct account, combining funds that share one. Bloomerang gifts, refunds, pledges and pledge payments are totalled per fund without ever adding a pledge to its payments, and Sage Intacct activity is read on an accrual basis so rows are not double counted. Each variance over one percent or 100.00 gets its likeliest cause from the evidence, and it says which pledge treatment your books appear to follow. It only reads, and reports mismapped funds rather than guessing the account.
Business outcome
---
Variances between donor records and the ledger arrive with explanations, so the close moves faster.
scenario
-
Gifts recorded in Bloomerang should match money arriving in Sage Intacct, but card processors pay out in batches net of fees, checks are bundled into deposits, and payment methods are named differently. Proving every gift reached the bank takes careful matching that rarely gets finished.
What popdock provides
--
Give a date range, and optionally a bank account, and it reads gifts and refunds from Bloomerang and the receipts, invoice payments and deposits in Sage Intacct, allowing three business days for settlement. Checks match on check number or amount and date, card and EFT gifts are batched by day with any shortfall reported as implied fees, and cash matches on amount, without counting the same money twice. You get matched items, gifts with no money, money with no gift, and refunds, ending with the unexplained difference. It only reads, and warns when a record limit means a list is partial.
Business outcome
---
You can show every gift reached the bank, with processor fees and unexplained differences called out.
scenario
-
Some donations go straight to finance and are recorded in Sage Intacct but never entered in Bloomerang, so donors miss acknowledgements and giving history is incomplete. Finding them means comparing receipts with gifts by payer, amount and date, and payers rarely appear exactly as constituents do.
What popdock provides
--
Give a date range, and optionally a minimum amount, and it reads Sage Intacct receipts, keeping only lines on the gift revenue accounts your Bloomerang funds map to. Each receipt is checked against Bloomerang by payer and by amount within seven days, and sorted into already recorded, ready to record or needs a person. You choose which ready gifts to create, and it asks rather than guessing on unclear payment methods or partly deductible receipts. It never adds a donor, reads back each new gift, and reminds you not to post these to Sage Intacct a second time.
Business outcome
---
Donations received by finance appear in Bloomerang, so donors are thanked and giving history is complete.
scenario
-
A donor may also be a customer with open invoices or a vendor your organization pays, and those records sit in Sage Intacct with no link to Bloomerang. Finding them means searching by name in several places, and people are often stored differently, so the wrong record is easy to pick.
What popdock provides
--
Give the donor's name, email or account number, and it totals their Bloomerang giving, then searches Sage Intacct customers, vendors and contacts. A record counts as a match only when the name agrees and the email or city agrees too; name-only hits are listed as possible matches and kept out of the totals. You see what they gave, what they owe on open invoices, what they paid and whether those payments also appear as gifts, and what was paid to them. A donor who is also a paid vendor is flagged for related-party review without concluding anything, and nothing is changed.
Business outcome
---
You see the whole financial relationship with a donor, including related-party items, before anyone has to ask.
scenario
-
Active customers in Sage Intacct should hear about your news and offers, but nobody adds them to Constant Contact as accounts are opened. Doing it by hand means checking each email, skipping anyone who unsubscribed, and recording consent truthfully for the whole batch.
What popdock provides
--
Name an existing Constant Contact list, and optionally a customer type or state, and it reads up to 200 active Sage Intacct customers and sorts each email into to add, unsubscribed, already on the list, or in Constant Contact but not on this list. Unsubscribed contacts are never added and the list is never created. You see the counts and the rows to add, and you say how these customers gave permission, explicit only if they opted in. Contacts are created after your yes, each address once, invalid emails are skipped and listed, and the list is checked afterwards.
Business outcome
---
Your Sage Intacct customers join your campaign list with honest consent and no unsubscribed contact added back.
scenario
-
When Sage Intacct invoices go past due, a reminder email is the cheapest first step, but only if it lands. Some customers have no email on file, some addresses bounce, and some people stopped opening your messages long ago, and you find out only when nothing gets paid.
What popdock provides
--
Optionally set how many days overdue counts, 30 by default, and a minimum total, and it groups past-due Sage Intacct invoices by customer with the total and oldest due date. Each email is checked in Constant Contact and placed in one group: reachable and engaged, reachable but not opening in 90 days, bouncing, unsubscribed, not in Constant Contact, or no email on file. The table is sorted by amount owed, with a recommendation for which groups need a phone call or letter. It leaves the decision about notices to unsubscribed customers to you, and nothing is sent or changed.
Business outcome
---
Collections picks the right channel for each overdue customer, rather than waiting on emails that never arrive.
scenario
-
Answering a simple question about one person, are they engaged and are they paying, means checking Constant Contact for their email history and Sage Intacct for their balance, open invoices and payments. Matching the two by company name alone risks pulling up the wrong account.
What popdock provides
--
Give an email address, and optionally a look-back period, 90 days by default, and it reads the person's Constant Contact sends, opens, clicks, bounces, unsubscribes and lists. The same email finds their Sage Intacct contact and customer account, with total due, credit limit, open invoices and the last payment. Matching is on email only, since a shared company name is not proof of the same person, and several matching customers are listed for you to choose. One line ties it together, such as engaged on email but 60 days overdue, and nothing is changed.
Business outcome
---
You see in one view whether a person is engaged with your emails and current on their account.
scenario
-
Marketing works in Constant Contact and rarely knows that a contact's company is over its credit limit or months behind on payments in Sage Intacct. Passing that context across usually means asking finance and pasting a summary into the contact record by hand.
What popdock provides
--
Give a Constant Contact contact's email, and optionally a look-back period, a year by default, and it finds the matching Sage Intacct customer through the same email. It summarizes total due against credit limit, open invoice count, oldest due date, last payment and total paid, with the currency on every amount. You see the dated note, under 600 characters and with no invoice numbers or bank details, before it is saved. It is added once after your yes and read back, and an account with nothing outstanding still gets a note saying it is clear.
Business outcome
---
Marketing sees a customer's account standing on their contact record before deciding what to send them.
scenario
-
Comparing active Sage Intacct customers with Constant Contact contacts is the kind of check nobody has time for, so missing customers, unsubscribed accounts and outdated company names or locations pile up. Doing it by hand means one lookup per customer and a careful eye for what is a real difference.
What popdock provides
--
Optionally set how many customers to check, 100 by default, and a customer type, and it reads active Sage Intacct customers and looks up each email in Constant Contact. Matches are compared on company name, city, state and country, treating case, punctuation, suffixes like Inc or LLC, and state codes versus full names as equal so only real differences show. You get missing customers, unsubscribed customers, differing details with both values, and customers with no email, plus the count that matched cleanly. A shared email is listed once as shared, it does not decide which system is right, and nothing is changed.
Business outcome
---
You see the real gaps between your accounting customers and your email audience, without false alarms from formatting.
scenario
-
After a campaign, leadership asks whether it produced any business. Answering means taking the click list from Constant Contact, finding which clickers are Sage Intacct customers, and adding up the quotes, orders and invoices they raised afterwards, without mixing currencies or document types.
What popdock provides
--
Name a Constant Contact campaign or give its id, and optionally a window, 30 days by default, and it collects the unique clickers, keeping the 50 most active if there are more. Each email is matched to a Sage Intacct contact and customer, and the order entry documents raised in the window after the send are listed. Totals are kept separate for quotes, orders and invoices and per currency, and a customer reached by two clickers is counted once. It states plainly that this is activity after the click, not proof the campaign caused it, and it only reads.
Business outcome
---
You can report the sales activity that followed a campaign, broken down honestly by document type and currency.
scenario
-
Finance asks how fundraising is tracking against budget, but gifts sit in DonorPerfect and the budget sits in Sage Intacct. Mapping GL codes to accounts, splitting pledges from payments and lining up budget periods is slow, and pledge payments are easy to count twice.
What popdock provides
--
Give a date range and optionally a budget, the default one if blank, and it totals DonorPerfect outright gifts, new pledges and pledge payments by GL code, keeping pledge payments separate so nothing is counted twice. Each code is mapped to its Sage Intacct account using DonorPerfect's own mapping, and the budget is read for whole periods only, never prorated. Revenue already posted in Sage Intacct is shown alongside, with not yet posted revenue and unbudgeted codes called out. Nothing is changed.
Business outcome
---
Leadership sees fundraising against budget by account, including gifts not yet in the ledger, without a manual crosswalk.
scenario
-
Posting each day's DonorPerfect gifts to Sage Intacct means totalling them by GL code, finding the right revenue account for each and building journal entries by hand. It is easy to post a day twice, or to post gifts that already arrived through a deposit.
What popdock provides
--
Give the gift date and a debit account, and it totals that day's outright DonorPerfect gifts by GL code and maps each code to its Sage Intacct revenue account, never guessing one. It checks for an existing entry with the same reference and for credits that already match the day's total, and asks for any required department or location. You approve a table of ready, already posted and unmapped codes, then one balanced entry per code is created as a draft unless you ask to post, and each is read back.
Business outcome
---
Daily gift revenue reaches Sage Intacct as balanced entries, one per GL code, with no day posted twice.
scenario
-
Auditors and finance teams need gift revenue in DonorPerfect to agree with what Sage Intacct posted, but differences hide in pledges, pledge payments and batch deposits. Finding which gifts are missing from the ledger, or which ledger rows no gift explains, takes days.
What popdock provides
--
Give a date range and optionally one GL code, and it splits DonorPerfect gifts into outright gifts, pledge payments and pledges for each code, then reads net posted revenue on the mapped Sage Intacct account. It tests which combination closes the gap, which shows how your organisation books pledges, then matches gifts to ledger rows one to one by amount and date, switching to daily totals when deposits are batched. Unmapped codes are reported, not guessed, and neither system is adjusted.
Business outcome
---
Gift revenue reconciles by GL code with every unmatched item named, ready for audit or month-end review.
scenario
-
Donations sometimes arrive straight into Sage Intacct as other receipts and never get entered in DonorPerfect, so donors go unthanked and giving history is incomplete. Finding them means comparing receipts on contribution accounts against gifts and then working out who each payer is.
What popdock provides
--
Give a date range and optionally a GL code, and it uses DonorPerfect's GL code mapping to find the Sage Intacct contribution accounts, reads the receipt lines on them and matches each to DonorPerfect gifts by amount and date, treating batch deposits as matched. For each unmatched line it proposes a donor, lists candidates, or says none was found. You choose which rows to record, each is checked again for an existing gift, and only then saved. Missing donors are listed for you to add, never created.
Business outcome
---
Donations received in the ledger find their way into DonorPerfect, so every donor is credited and thanked.
scenario
-
Related-party reviews, such as for an audit or Form 990, ask what the organisation paid to board members, their family and their businesses. Board members are flagged in DonorPerfect, payments live in Sage Intacct, and matching names between the two by hand is slow and unreliable.
What popdock provides
--
Name the flag, BOARD by default, and a date range, and it lists the flagged DonorPerfect donors and the donors linked to them. Each is searched among Sage Intacct vendors and graded strong or possible, with name-only matches never graded above possible; flagged people who are employees are noted. Payments and bills are totalled for each matched vendor. Unmatched donors are listed to show they were checked, and the report states findings, not conclusions. Nothing is changed.
Business outcome
---
Your related-party review starts from a complete, graded list of payments, with every flagged person accounted for.
scenario
-
When a donor asks whether their gift was received, or an auditor picks one gift to test, someone has to search Sage Intacct for a matching receipt, payment or ledger entry. Batch deposits and check numbers that do not match make one gift surprisingly hard to find.
What popdock provides
--
Give a DonorPerfect gift id and a window of days, 5 by default, and it reads the gift and its donor, explaining when a soft credit or pledge has nothing to trace. It maps the GL code to its Sage Intacct account, then searches by check reference, ledger amount and other receipts around the gift date. Each hit is graded confirmed or possible, possible is never reported as confirmed, and if nothing matches it lists larger rows that could be batch deposits. It is read-only.
Business outcome
---
You can show exactly where a gift landed in Sage Intacct, or prove it never arrived, in one read.
scenario
-
During a move from Dynamics GP to Sage Intacct, a vendor invoice can turn up after cutover that was already entered or even paid in the old system. Checking means searching GP payables and payments, then Intacct bills, by invoice number or amount, and invoice numbers rarely match exactly.
What popdock provides
--
Give the vendor and the invoice number or amount, and it searches Dynamics GP payables, including voided documents, and the payments applied to each match. It then searches Sage Intacct bills and payments, finding the vendor by name if the ID differs, and compares invoice numbers ignoring case, spaces, dashes and leading zeros. You get one verdict first, from safe to paid in GP or in both, followed by the evidence. Near matches are shown as possible matches but never decide the verdict, and nothing is changed in either system.
Business outcome
---
No invoice gets paid twice across the cutover, and each verdict comes with the payment evidence behind it.
scenario
-
After moving from Dynamics GP to Sage Intacct, GP main accounts that never made it into the new chart cause failed imports and postings. Creating them by hand means working out each account's type, normal balance and closing behavior from GP, one account at a time.
What popdock provides
--
Optionally choose a main segment, and it compares active Dynamics GP main accounts with the Sage Intacct chart, leaving out any that look already mapped under a similar title. For each gap it proposes the number, title, account type, normal balance and closing treatment, asks once for the retained earnings account, and flags segments whose GP descriptions differ. You confirm, edit or drop rows, up to 50 at a time. Only confirmed accounts are created, it stops on the first failure, and each new account is read back. Dynamics GP is never written to.
Business outcome
---
Your Sage Intacct chart gains the missing GP accounts with the right type and balance, each approved by you.
scenario
-
Mapping a segmented Dynamics GP chart of accounts to Sage Intacct is slow and error prone. GP accounts have to be rolled up by main segment, matched despite leading zeros, and checked for type and normal balance, while segments hiding several meanings need a decision about dimensions.
What popdock provides
--
Optionally pick a main segment, and it reads active Dynamics GP accounts grouped by main segment and the Sage Intacct chart. Segments are matched exactly, then without leading zeros, and close title matches are listed as suggestions that never count as matches. Each pair is checked for account type, normal balance and an inactive Intacct account. You get counts, mismatches, GP-only and Intacct-only accounts, and segments that may need a dimension or separate accounts. It only reads.
Business outcome
---
You know exactly how the GP chart maps to Sage Intacct, and which accounts still need a decision, before go-live.
scenario
-
Moving customers from Dynamics GP to Sage Intacct leaves gaps: some never came across, some came across under a new ID, and hold status or credit limits are lost on the way. Creating the missing ones by hand risks duplicates and wrong payment terms.
What popdock provides
--
Optionally pick a GP customer class, and it reads active Dynamics GP customers and checks each in Sage Intacct by ID, then by name. A name match under a different ID is listed as possibly migrated and never created. For the rest it proposes name, address, email, phone and a payment term you confirm the mapping for, showing credit limits as not carried. You confirm up to 25 at a time, customers on hold in GP are put on hold in Intacct, and each one is read back. Dynamics GP is never written to.
Business outcome
---
Missing customers reach Sage Intacct once, with hold status kept and credit limits listed for you to set.
scenario
-
After a Dynamics GP to Sage Intacct cutover, vendors that did not migrate block bill entry and payments. Adding them by hand risks creating a second record for a vendor that came across under a new ID, and payment terms that Intacct rejects.
What popdock provides
--
Optionally pick a GP vendor class, and it reads active Dynamics GP vendors and checks each in Sage Intacct by ID, then by name, never creating one that may have migrated under another ID. It proposes name, email, phone and a payment term only once you confirm the mapping, and lists GP addresses as not carried so you can enter them. You confirm up to 25 at a time, vendors on hold in GP are put on hold in Intacct, and each one is read back. Dynamics GP is never written to.
Business outcome
---
Every active GP vendor exists once in Sage Intacct, so bills and payments can carry on after cutover.
scenario
-
When one account in Sage Intacct does not tie to its Dynamics GP balance at cutover, someone has to work out the GP balance from period summaries, net the Intacct ledger to the same date and key a correcting entry against a clearing account. Get the sign or the period wrong and the difference doubles.
What popdock provides
--
Name the account, the cutover date and a clearing account, and it asks for the GP fiscal year and last period, then works out the Dynamics GP balance and the Sage Intacct balance at cutover. If they tie it stops. Otherwise it proposes one journal entry for the difference, saved as a draft unless you ask to post, and warns when the gap is over 10 percent, suggesting a full trial balance check first. Nothing is written until you confirm, it refuses if both accounts are the same, and it checks the account ties afterwards.
Business outcome
---
Cutover differences are corrected with one confirmed entry, and you see the account tie afterwards.
scenario
-
Proving inventory came across from Dynamics GP to Sage Intacct correctly means pairing GP sites with Intacct warehouses, then comparing quantity and value item by item. Live activity on either side since cutover muddies the comparison further.
What popdock provides
--
Optionally pick a site or item, and it pairs Dynamics GP sites with Sage Intacct warehouses, then reads GP quantities and costs by site and Intacct on-hand and costs by warehouse. Items are matched by number and compared on quantity and on value using the matching cost method. You get items missing from Intacct, quantity differences by value, cost differences over 1 percent, and totals per site. Non-inventory items are skipped and counted, and it warns that differences may reflect activity since cutover. It only reads.
Business outcome
---
Inventory is proven to match after the move, or the exact items and sites that differ are listed.
scenario
-
Confirming that every open payable in Dynamics GP came across to Sage Intacct is hard when GP stayed in use after cutover and payments have reduced what is open. Vendor IDs and invoice numbers also drift, so a simple total comparison hides missing bills.
What popdock provides
--
Give the cutover date, and optionally a vendor, and it works out what was open in Dynamics GP at cutover, adding back payments applied since. It reads open Sage Intacct bills and credit adjustments, matches vendors by ID, then by name, and matches documents by bill or reference number. You get vendors that do not tie, GP documents missing from Intacct, Intacct bills with no GP source, amount or due date mismatches and grand totals. Missing bills are listed for import, never created.
Business outcome
---
Accounts payable opens in Sage Intacct with every cutover bill accounted for, or a clear list to import.
scenario
-
After moving to Sage Intacct, finance has to prove every customer balance open in Dynamics GP at cutover arrived as an open invoice. Payments applied in GP after cutover, changed due dates and drifting customer IDs make that much harder than comparing totals.
What popdock provides
--
Give the cutover date, and optionally a customer, and it works out each customer's open Dynamics GP receivables at cutover, adding back amounts applied since. It reads open Sage Intacct invoices and credit adjustments, matches customers by ID, then by name, and matches documents by invoice or reference number. You get customers that do not tie, documents missing on either side, amount and due date mismatches and grand totals. Unapplied GP payments still count as open items, and missing invoices are listed for import. It only reads.
Business outcome
---
Receivables balances are proven complete after cutover, so aging and dunning in Sage Intacct start from the right numbers.
scenario
-
Signing off a move from Dynamics GP to Sage Intacct needs proof that every account balance matches at cutover. That means adding GP period balances differently for balance sheet and profit and loss accounts, rolling segments up to main accounts and netting the Intacct ledger to the same date.
What popdock provides
--
Give the GP fiscal year and period and the cutover date, and it builds Dynamics GP balances from beginning balance or year to date as each account requires, rolled up by main segment. It nets Sage Intacct ledger detail for each account to the same date and first checks each side nets to zero. You get totals, every difference largest first, and accounts on one side only, with a note when the differences look like an offset in one clearing account. It never compares full segmented numbers directly, and nothing is posted.
Business outcome
---
You can sign off the cutover with an account by account proof that the opening position matches.
scenario
-
After a cutover, a customer's history is split: older sales and receivables live in Dynamics GP and newer invoices and payments in Sage Intacct. Seeing the whole picture means two lookups and care not to count migrated invoices twice, and differences in terms or credit limit go unnoticed.
What popdock provides
--
Give the customer ID and how many months to look back, and it finds the customer in Dynamics GP and Sage Intacct and lists any differences in terms, credit limit, status, email or city. It reads GP receivables and sales documents and Intacct invoices, payments and orders, splitting the timeline at cutover and showing migrated invoices once. You get monthly totals tagged by system, the open balance, any GP document that did not migrate, the last ten documents and a one-line read on buying and paying. It only reads.
Business outcome
---
You see one customer's full history across both systems, with settings that did not carry across called out.
scenario
-
Building a collections list in Sage Intacct means exporting open invoices, aging them by hand, then opening each customer to check credit limits, recent payments and open credits. Partly paid invoices and unapplied cash make some customers look worse than they are, and the ones who really need a call get buried.
What popdock provides
--
Set a minimum number of days overdue and an as-of date, and it pulls every open Sage Intacct invoice past due, ages the balances into 30 day buckets and ranks customers by what they owe. For each ranked customer it adds the credit limit, terms, rep, last payment and any open credits, and flags possible unapplied cash. Totals stay separate per currency, and each customer gets a suggested next step. It only reads, so credit holds and other changes stay with you.
Business outcome
---
Your collections team starts each day with a ranked, aged worklist and a clear next step for every overdue customer.
scenario
-
Before closing a period in Sage Intacct you have to hunt through journal entries, bills, invoices, bank reconciliations, timesheets and expense reports for anything still open. Each check lives on a different screen, and one missed unposted entry or unreconciled account can force you to reopen the books.
What popdock provides
--
Give a period end date and it checks Sage Intacct for unposted journal entries, draft or declined subledger documents, recurring bills and invoices that did not run, bank and card accounts not reconciled through the period, stale uncleared deposits and payments, unapproved timesheets and expense reports, and goods received but not invoiced. Expected items such as auto-reversing accruals are noted separately from real blockers. Any check that fails is marked could not check, never clear, and nothing in Intacct is changed.
Business outcome
---
You know exactly what still blocks the close before you start it, so the books do not have to be reopened later.
scenario
-
Comparing budget to actuals in Sage Intacct usually means two exports, a spreadsheet and a lot of sign flipping so revenue and expense line up. Then you still have to dig through the ledger to explain why an account ran over, and rows repeated per reporting method can quietly double the numbers.
What popdock provides
--
Give a start date, and optionally a budget and a variance threshold, and it reads the budget amounts and posted actuals by GL account from Sage Intacct using one reporting method, so nothing is counted twice. Each account gets its variance in amount and percent, marked favorable or unfavorable, and every account over the threshold is flagged. For the five largest unfavorable variances it names the vendors, customers or journals behind them. It is read-only and notes that accounts with no budget line are not covered.
Business outcome
---
You get a variance report with the drivers already named, ready for review without a spreadsheet rebuild.
scenario
-
Entering a sales order in Sage Intacct means finding the right customer among similar names, checking their credit, looking up each item and whether there is stock to sell. Pick the wrong customer or an inactive item and the order has to be corrected or voided later.
What popdock provides
--
Name the customer and the items, and optionally a quote or invoice type and a PO number, and it finds exactly one active customer and one active item per line in Sage Intacct. It warns when the order would push the customer over their credit limit or when stock is short, and checks the transaction type is one your company uses. You see the full draft and nothing is created until you say yes, then the new document is read back to confirm its number, total and lines.
Business outcome
---
Orders land against the right customer and items the first time, with credit and stock warnings seen before you commit.
scenario
-
When a GL account moves more than expected, working out why means scrolling ledger detail in Sage Intacct, grouping by vendor or journal in a spreadsheet and comparing with last period by hand. Manual entries, accruals that reverse next month and possible duplicates are easy to miss in a long list.
What popdock provides
--
Name the account and a date range, and it reads the Sage Intacct ledger detail for the period and the one before, then breaks the movement down by journal, counterparty, department and project. Manual entries are traced to their journal entry and the other side of the posting, and source bills or invoices are pulled where they apply. Accruals that reverse next period are called out as temporary. Entries are presented as worth checking, never as errors, and nothing is changed.
Business outcome
---
You can explain a surprising account balance in one read, with the entries that need a second look already listed.
scenario
-
Duplicate vendor bills slip into Sage Intacct when an invoice arrives by email and post, or a bill number is keyed with a different format. Spotting them means sorting hundreds of bills by vendor and amount, and by the time anyone notices, both copies may already be paid.
What popdock provides
--
Set a lookback window, and optionally a vendor, and it compares recent Sage Intacct bills by bill number, amount, date, reference and near-identical vendor names. Same-amount bills that match an active recurring template are ruled out as rent or subscriptions. Each candidate is checked against its lines and payment history, so you see which pairs were paid twice and the total exposure. Every group is presented as a candidate to review, and nothing is voided or changed.
Business outcome
---
Double payments are caught before the next payment run, and refunds can be requested for the ones already paid.
scenario
-
Knowing how much cash you need for vendors over the next month means listing open bills in Sage Intacct, adding the recurring bills that have not generated yet and netting out open debit memos. Doing it by hand in a spreadsheet means past-due bills and projected charges often get mixed together.
What popdock provides
--
Choose how many days ahead to look, and it reads open Sage Intacct bills and upcoming recurring bills and puts them week by week, keeping real bills, projected recurring charges and past-due amounts on separate lines. For the top ten vendors it adds payment priority, terms and open debit memos. It sets the cumulative requirement against each bank account's last reconciled balance and says clearly that this is not today's balance. Amounts stay per currency and nothing is paid or scheduled.
Business outcome
---
You see week by week how much vendor cash you need and where it may run short, before the bills come due.
scenario
-
Posting a quick journal entry in Sage Intacct sounds simple, but the account may only accept subledger postings, may require a department or location, or the same entry may already be in. Get any of those wrong and the entry is rejected or the books are double booked.
What popdock provides
--
Give a description, the debit and credit accounts and the amount, and it checks that both accounts exist in Sage Intacct, accept journal entries and have any required department or location. It looks for a similar entry on the same date and asks before going further if one exists. You see the balanced two-line entry, and whether it will post or save as a draft, and nothing is written until you confirm. The new entry is then read back to confirm its transaction number and both lines.
Business outcome
---
Simple adjustments are booked correctly the first time, with no rejected postings or duplicate entries to unwind.
scenario
-
Preparing for a customer call means opening Sage Intacct screens for open invoices, payments, credits, sales orders, recurring billing and projects, then piecing together how the account is really doing. It takes long enough that most reviews only look at the balance.
What popdock provides
--
Name the customer, and it builds a one-page review from Sage Intacct: profile, open and overdue receivables with aging, average days to pay against terms, recent payments and credits, open quotes and orders, recurring billing, projects and contacts. It closes with a few risks and opportunities, such as slowing payment or a quote still open. It says when a payment trend rests on fewer than three paid invoices, keeps currencies apart, and changes nothing.
Business outcome
---
You walk into every customer conversation knowing the balance, the payment habits and the open opportunities on one page.
scenario
-
Deciding what to reorder in Sage Intacct means comparing on-hand and on-order quantities with recent sales, item by item, and spotting the stock that has not moved in months. Counting a converted order and its invoice as two sales, or forgetting open purchase orders, sends the numbers the wrong way.
What popdock provides
--
Name a warehouse, or leave it blank for all, and it reads Sage Intacct stock levels and recent sales to work out daily demand, counting each sale once. It lists stock-outs with the purchase documents that will cover them, items to reorder with a suggested quantity, slow-moving stock by value and any negative on-hand counts. It notes that lead times and minimum order sizes are not in the data, and it does not create purchase orders or change anything.
Business outcome
---
You get a reorder list and a view of dead stock in one pass, so cash is not tied up in the wrong items.
scenario
-
Projects in Sage Intacct can look fine on percent complete while the budget is nearly spent, tasks are overdue and nobody has logged time in weeks. Checking that across every active project means opening each one and comparing several numbers by hand.
What popdock provides
--
Name a project, or ask for every active one, and it rates each red, amber or green from Sage Intacct budget burn against percent complete, end dates, overdue tasks and recent time entries. The rules are stated, such as burn 20 points ahead of completion meaning red, and the numbers behind every rating are shown so you can disagree with it. A single project review adds overdue tasks, hours by person and suggested actions. It only reads.
Business outcome
---
Project managers spot overruns and stalled projects early, with the evidence behind each rating in plain view.
scenario
-
Setting up a project in Sage Intacct means checking it does not already exist, finding the right customer and manager records, picking a category and then adding each task one by one. A duplicate project or a task on the wrong project has to be fixed directly in Intacct afterwards.
What popdock provides
--
Give the project name, customer, manager and a task list, and it first checks Sage Intacct for a project with the same or a similar name. The customer and manager must each match exactly one active record, and the category and task status are taken from values Intacct already uses. You see the full setup and nothing is created until you confirm. The project and its tasks are then created and read back, and if the new project cannot be found, no tasks are added and it is not created twice.
Business outcome
---
New projects start clean, with the right customer, manager and tasks, and no duplicates to untangle.
scenario
-
Keeping a Mailchimp audience in step with your Sage Intacct customers means exporting emails, comparing them with the audience and importing the gaps. Do it carelessly and you re-add people who unsubscribed or were cleaned, or add people without the consent Mailchimp requires.
What popdock provides
--
Name the audience, and it finds active Sage Intacct customers whose email is not in that Mailchimp audience, using contact names where exactly one contact matches rather than guessing. New people are added as pending, so they get a double opt-in email, unless you choose otherwise, and choosing subscribed asks you to confirm you have consent. Anyone already in the audience, including unsubscribed or cleaned addresses, is skipped and listed. You confirm the plan before anyone is added, and each add is checked afterwards.
Business outcome
---
Your audience covers every active customer without ever re-adding someone who unsubscribed or skipping consent.
scenario
-
Collections reminders sent by email often go nowhere because the customer unsubscribed, the address bounced or it was never in your mailing system. Checking every overdue customer's contacts against Mailchimp by hand takes so long that teams just send and hope.
What popdock provides
--
Set how many days overdue to look at, and it lists Sage Intacct customers with past-due invoices, gathers every email on the customer and its contacts, and checks each one in Mailchimp. Addresses are sorted into reachable, opted out, bad address or not in Mailchimp, using audience status and recent hard bounces. The report ranks customers by overdue total and lists who needs a phone call or a new address. It is read-only and treats Mailchimp status as evidence, not a legal opinion.
Business outcome
---
Collections knows up front which email reminders will land and who needs a phone call instead.
scenario
-
When a store buyer known to Mailchimp needs to become a billing customer, someone retypes their details into Sage Intacct. Without checking first it is easy to create a second customer for someone already set up under a business name or a contact record.
What popdock provides
--
Give the buyer's email, and it reads the Mailchimp store customer, then searches Sage Intacct by contact email, company name and any customer ID you supplied. If a matching customer exists or the ID is taken, it shows it and stops rather than creating a duplicate. You review and can correct the values, with fields left blank rather than guessed, and nothing is written until you confirm. The new customer is then read back from Intacct to prove it exists.
Business outcome
---
Store buyers become billing customers in one step, without duplicate records in your ledger.
scenario
-
Finance sees a customer's invoices in Sage Intacct, marketing sees their engagement in Mailchimp, and nobody sees both. Before chasing a late payer or planning outreach, you end up asking two teams and matching email addresses yourself.
What popdock provides
--
Name the customer, and it reads their status, terms, credit limit and open invoices from Sage Intacct, then gathers every email on the account and its contacts. Each address is looked up in Mailchimp for audience status, rating, open and click rates, recent opens, clicks and bounces, campaign unsubscribes and store spend. You get one profile with a few plain observations, such as an overdue customer whose only address is unsubscribed. Nothing is changed, and if Mailchimp is unavailable you still get the Intacct half.
Business outcome
---
Finance and marketing work from the same view of a customer, so outreach and collections stop working against each other.
scenario
-
Store buyers show up in Mailchimp e-commerce data long before anyone sets them up in Sage Intacct, and some never get set up at all. Matching store customers to billing customers by email and company name by hand is slow, and a loose company match produces false links.
What popdock provides
--
Set a minimum order count, and it lists Mailchimp store customers and looks each one up in Sage Intacct by contact email first, then by company name. A company name alone never counts as a match, so customers are sorted into matched, possible match and not in Intacct. For matched customers it sets store spend next to invoiced totals and flags buyers Intacct has never invoiced. It only reads and points you to a separate step for creating any missing customers.
Business outcome
---
You see which paying store buyers are missing from your ledger, ranked by spend, without a manual matching exercise.
scenario
-
Marketing keeps sending promotions to customers who are well behind on their invoices, because overdue status lives in Sage Intacct and the mailing list lives in Mailchimp. Building an exclusion tag means pulling overdue accounts, finding their emails and tagging each one by hand.
What popdock provides
--
Name the overdue threshold, the audience and an existing static tag, and it finds Sage Intacct customers past due and collects every email on the account and its contacts. Only people already in the Mailchimp audience are tagged, so nobody is ever added to the audience itself, and anyone already tagged is skipped. You see the plan with each member's status and confirm before any tag is applied, then each one is checked to make sure it landed. It stops if the tag does not exist or is condition based.
Business outcome
---
Marketing can exclude or target overdue customers from a reliable tag, kept in step with your receivables.
scenario
-
After a campaign goes out, marketing can see clicks in Mailchimp but not whether those people went on to buy, because orders and invoices live in Sage Intacct. Matching clickers to customers and pulling their sales for the following weeks is a long manual job.
What popdock provides
--
Name a sent Mailchimp campaign and a window of days, and it collects everyone who clicked, matches their emails to Sage Intacct customers and groups several clickers from the same company. For each matched customer it lists the sales orders and invoices in the window and totals the invoiced amount, without double counting an order and the invoice it became. It reports unmatched clickers, cuts the window at today, and states plainly that this shows what followed, not that the campaign caused it. Nothing is changed.
Business outcome
---
You can show what clicking customers went on to buy after a campaign, with an honest invoiced total.
scenario
-
Prices and costs drift apart when someone updates Shopify but not Sage Intacct, or the other way round. Checking SKU by SKU means opening each variant, its inventory cost and the matching Intacct item, and a product quietly selling below cost can go unnoticed for months.
What popdock provides
--
Name a SKU or a product vendor, and it reads each Shopify variant's price and cost and the matching Sage Intacct item's base price and standard or average cost. Rows are flagged when price or cost differs beyond your tolerance, when the Shopify price is below either cost, or when a cost is missing, and flagged rows come first. Items with no Intacct base price are reported as priced by price list rather than as mismatches, and different currencies are not compared. It recommends fixes but changes nothing.
Business outcome
---
You catch pricing mismatches and negative margins before they cost you, with a SKU list ready to correct.
scenario
-
Shopify B2B companies are meant to point at their Sage Intacct customer through an external ID, but links go missing, point at deleted customers or drift as names change. Finding the broken ones means checking each company against Intacct by hand.
What popdock provides
--
Set how many companies to check, and optionally a name filter, and it reads your Shopify B2B companies and looks up each external ID in Sage Intacct. Companies are grouped as linked with a name difference, broken link, or unlinked with a single candidate, several candidates or no customer at all, worst first and sorted by spend. A candidate found by name is shown as a suggestion, never as a link. It only reads and points you to a separate step for fixing a company.
Business outcome
---
You know which B2B accounts are not tied to your ledger, starting with the most valuable, before orders and invoices go astray.
scenario
-
When a Shopify B2B company is not linked to its Sage Intacct customer, orders and invoices cannot be tied together. Fixing it means finding the right customer, creating one if none exists, and pasting the ID into the right Shopify field without overwriting a link someone else set.
What popdock provides
--
Name the company, and it finds it in Shopify and checks whether its existing link already resolves in Sage Intacct. If not, it looks for the customer by name, letting you choose when there are several, and only offers to create one when none exists, using the main contact and location details from Shopify. Each write, the new customer and the Shopify link, needs its own yes, and an old broken link is shown before it is replaced. If the customer cannot be created, Shopify is left untouched, and the link is read back at the end.
Business outcome
---
Each B2B company ends up tied to exactly one ledger customer, with nothing written you did not approve.
scenario
-
Money collected in Shopify reaches the bank days later, net of fees, so lining up daily takings with Sage Intacct deposits is guesswork in a spreadsheet. A payout that never arrived, or arrived short, can hide among normal fee gaps.
What popdock provides
--
Give a date range, and optionally a payment gateway, and it totals successful Shopify sales, captures and refunds by day, ignoring authorizations, voids and failures. It lines each day up with Sage Intacct deposits up to five days later within five percent, labels small gaps as likely fees and larger ones as mismatches, and lists days and payout-like deposits with no partner. The report says at the top that this is a date and amount match to check, not proof, and nothing is changed.
Business outcome
---
You get a short list of collection days that never reached the bank, so missing payouts are chased early.
scenario
-
Getting a Shopify order into Sage Intacct by hand means finding the right customer, matching each product to an item by SKU and checking nobody already posted it. Miss that last check and the same order is billed twice.
What popdock provides
--
Name the Shopify order, and it reads the order and its lines, then searches recent Sage Intacct invoices and documents for one carrying the same order number and stops if it finds it. The customer is found through the B2B company link, a contact email or the customer name, and you are asked rather than having one created. Every line must match exactly one Intacct item by SKU, orders over two lines are refused, and you are told that tax, shipping and discounts do not carry across. Nothing is posted until you confirm, and the new document is read back.
Business outcome
---
Shopify orders reach your ledger once, against the right customer and items, with no double billing.
scenario
-
Every Shopify order is supposed to end up in Sage Intacct, but integrations miss some and others arrive with a different total. Checking means matching order numbers against reference and PO fields across two exports, usually only after month end is already under way.
What popdock provides
--
Give a date range, and it reads non-canceled Shopify orders and the Sage Intacct invoices and order documents from the same period plus a week. Orders are matched on their order name or number against the Intacct reference or PO number, and each document matches only one order. You get the orders missing from Intacct, those with a different total, with a note when the gap looks like shipping or tax, and Intacct documents that look like orders but match nothing. It is read-only and says when the result is partial.
Business outcome
---
Missing and mismatched orders surface in minutes, so revenue in your ledger matches what the store sold.
scenario
-
When Shopify shows stock that Sage Intacct says is gone, or the reverse, you oversell or leave sellable items hidden. Comparing quantities item by item across systems and locations takes so long that it rarely happens.
What popdock provides
--
Name a SKU or check up to a set number of active stocked items, and it reads Sage Intacct on-hand quantities and sums Shopify available stock across locations for the exact same SKU. Rows where the two differ by your minimum are listed, largest gap first, along with SKUs found in only one system. Locations are paired only where names match exactly, never guessed, and duplicated SKUs in Shopify are flagged rather than summed. It explains that committed orders cause small expected gaps and changes nothing.
Business outcome
---
You see exactly which SKUs are out of step between store and ledger, before they cause oversells or missed sales.
scenario
-
A B2B buyer can keep ordering in Shopify while their unpaid invoices pile up in Sage Intacct, and nobody sees both numbers together. Working out real exposure means adding the ledger balance to orders not yet invoiced and comparing it with a credit limit kept somewhere else.
What popdock provides
--
Name the company, and it finds it in Shopify, follows its link to the Sage Intacct customer, or a single name match that it labels as such, and reads the balance, overdue invoices, terms and credit limit. It adds open Shopify orders not yet invoiced, leaving out any already billed, to show total exposure against the limit with the headroom or overage. Recent payments and any mismatch between Shopify and Intacct payment terms are called out. It recommends actions such as a hold but changes nothing.
Business outcome
---
You know a B2B buyer's true exposure before approving the next order, not after the invoice goes unpaid.
scenario
-
Each month someone has to total Stripe processing fees and book them in Sage Intacct as a journal entry. The fees are spread across thousands of balance transactions, and without a check it is easy to book the same month twice or post to an account that does not take journal entries.
What popdock provides
--
Name the month, and it totals Stripe fees from the balance transactions per currency and by type. You choose the expense and clearing accounts from Sage Intacct, which are checked to be active and open to journal entries, and it is never picked for you. It checks for an entry already booked for that month or Stripe fees already on the account, then shows the balanced entry and waits for your approval. The entry is created once and read back with both lines.
Business outcome
---
Stripe fees are booked once a month to the right accounts, with no double entries to reverse later.
scenario
-
New customers sign up through Stripe every week, and someone has to set each one up in Sage Intacct before they can be invoiced or reported on. Retyping names and addresses is slow, and a slightly different spelling creates a duplicate customer.
What popdock provides
--
Choose a start date, and optionally a name filter and payment term, and it lists new Stripe customers and checks each against Sage Intacct by email and by name, ignoring case, punctuation and suffixes such as Inc or LLC. Close but unequal names are shown as possible matches and never created. You approve all, some or none, and only approved customers are created, each read back to confirm. It stops rather than proposing everyone if Intacct returns nothing, which usually means the wrong company.
Business outcome
---
Stripe sign-ups become ledger customers in one approved batch, without duplicates to merge later.
scenario
-
Stripe pays out in lump sums net of fees, sometimes combining several days, so matching payouts to Sage Intacct bank deposits by hand is fiddly. A failed payout that was still recorded as a deposit means your books show money that never arrived.
What popdock provides
--
Give a date range, and it confirms which Sage Intacct bank account Stripe pays into, asking you when there is more than one. Paid and in-transit Stripe payouts are matched to deposits by exact amount and a date window, then to other receipts and to deposits that combine two or three payouts. You get matched pairs, payouts with no record, deposits with no payout, and failed or canceled payouts, flagged if one was deposited anyway. It only reads.
Business outcome
---
Every Stripe payout is accounted for in the bank, and deposits recording money that never came are caught.
scenario
-
Customers set up in Stripe often never make it into Sage Intacct, or their name, email and address drift apart over time. A customer who is behind in Stripe may look fine in Intacct. Checking by eye across two systems misses most of it.
What popdock provides
--
Choose a start date, and optionally a name filter, and it matches Stripe customers to Sage Intacct by email, then by name ignoring case, punctuation and company suffixes. Close names and same-domain emails are listed for a person to decide rather than treated as matches. For matched pairs it shows differences in email, city, state and country, and puts Intacct balance and status next to customers Stripe marks as delinquent. It is read-only and stops if Intacct returns nothing.
Business outcome
---
Your customer records agree across billing and accounting, and customers falling behind in Stripe are visible in finance.
scenario
-
When invoices live in both Stripe and Sage Intacct, a payment collected in Stripe may never be applied in Intacct, leaving a customer chased for money already paid. Finding those cases means matching invoices by number, amount and date across two exports.
What popdock provides
--
Give a date range, and optionally a customer, and it reads Stripe and Sage Intacct invoices, matching by invoice or reference number and, only if no numbers line up, by customer, amount and date, labelled as inferred. Invoices paid in Stripe but still due in Intacct come first, then the reverse, uncollectible invoices still due, and amount differences. Invoices on one side only are listed, and different currencies are never matched. It only reads and says when results are capped.
Business outcome
---
Customers are never chased for invoices they already paid, because unapplied payments are found before statements go out.
scenario
-
Refunds, credit notes and lost disputes in Stripe all reduce what customers owe, but each one has to be recorded in Sage Intacct by hand. The ones that slip through leave receivables overstated, and tracing them back to invoices takes ages.
What popdock provides
--
Give a date range, and it reads issued Stripe credit notes, successful refunds and lost disputes, counting a refund behind a credit note only once, and finds the invoice number behind each. It matches them to Sage Intacct AR adjustments by invoice number and amount, then by customer, amount and date, labelled inferred, and finally looks for a matching ledger entry. Open disputes are left out because no money is lost yet. It reports what is missing by type and changes nothing.
Business outcome
---
Every refund and lost dispute is reflected in receivables, so your AR balance matches the money actually returned.
scenario
-
Answering a simple question about a customer often means opening Sage Intacct for invoices and payments and Stripe for subscriptions, failed charges and disputes. Problems that show up on only one side, such as a paid invoice still due in the ledger, get missed.
What popdock provides
--
Name the customer or an email, and it finds them in Stripe and Sage Intacct, preferring a matching email and listing candidates rather than guessing. You get the Intacct balance, credit limit, open and past-due invoices and recent payments, next to Stripe subscriptions, open invoices, failed or disputed charges and open disputes. A needs attention list covers overdue balances, delinquency, subscriptions set to cancel and invoices paid in Stripe but due in Intacct. Nothing is changed in either system.
Business outcome
---
You see a customer's whole billing picture on one page and know exactly what needs attention first.
scenario
-
People log their hours in Teamwork.com as they work, then fill in Sage Intacct timesheets separately for billing and payroll. Checking that one person's two records agree means exporting both, converting minutes to hours and lining projects and days up by hand.
What popdock provides
--
Name the person and a date range, and it finds them in Teamwork.com and Sage Intacct, stopping if either name matches more than one person. It totals their time by project and by day on both sides, treating gaps under a quarter of an hour as matching, and lists days where only one system has time. It also shows whether the Intacct entries are still draft, submitted or approved, and notes when a gap may close once drafts are submitted. Nothing is changed in either system.
Business outcome
---
You can confirm one person's billable time is fully on their timesheet before it is approved or invoiced.
scenario
-
Delivery teams track a project's health, milestones and budget in Teamwork.com while finance tracks its contract, costs and invoices in Sage Intacct. When the two tell different stories, nobody notices until the project is over budget or the client is far behind on payment.
What popdock provides
--
Name the project, and it reads the Teamwork.com health score, budget used, late milestones and open risks, then the Sage Intacct contract amount, actual cost, percent complete and the customer's open invoices. It compares budget used with cost against contract, and milestone progress with Intacct percent complete, calling out any gap over 15 points. It notes that open invoices cover the whole customer, skips percentages when the contract value is missing, and closes with a short note on what needs attention. Nothing is changed.
Business outcome
---
Delivery and finance see the same project picture, so overruns and billing gaps are raised while they can still be fixed.
scenario
-
Before a project can be set up for a new client in Teamwork.com, someone has to create the client company, usually by retyping details from Sage Intacct. Without a check first, it is easy to create a second company for a client that is already there under a slightly different name.
What popdock provides
--
Name the customer, and it reads their details from Sage Intacct, stopping if the name matches more than one. It checks Teamwork.com for a company with the same or a very similar name and stops rather than creating a duplicate. You see the company to be created, with the country code only filled in when it can be converted with certainty, and nothing is written until you confirm. Any missing email or address details are named in the result.
Business outcome
---
New clients appear in Teamwork.com once, ready for projects, without duplicate companies to tidy up.
scenario
-
Project teams keep doing billable work for clients who are months behind on their invoices, because overdue balances sit in Sage Intacct and the teams live in Teamwork.com. By the time someone raises it, more unbilled work has piled up.
What popdock provides
--
Name the client and an overdue threshold, and it checks Sage Intacct for invoices past due, totalling the amount and noting the oldest due date. It finds the client's active Teamwork.com projects and skips any that already carry an open risk about overdue invoices. You see the risk text and the projects it will go on, and nothing is added until you confirm, then each new risk is read back. The risk mentions only the overdue total, never invoice numbers, since project members may not have finance access.
Business outcome
---
Project teams know when a client is behind on payment before committing more billable work.
scenario
-
Projects get created in Teamwork.com for delivery and in Sage Intacct for billing, and over time the two lists drift. A project missing from Intacct means time that never gets billed, and spotting it means comparing two long lists with different naming habits.
What popdock provides
--
Optionally name a client, and it reads active Teamwork.com projects and open Sage Intacct projects and matches them by name, ignoring case, punctuation and leading project codes. Names that only partly match with the same client are listed as probable matches for you to judge, not counted as matched. You get projects in Teamwork.com only, in Intacct only, and the count of exact matches. It is read-only and stops rather than listing everything when one side returns nothing.
Business outcome
---
Both systems track the same projects, so delivery work does not go unbilled because a project was never set up.
scenario
-
Before billing a project, someone has to check that every hour logged in Teamwork.com made it onto a Sage Intacct timesheet. Comparing person by person across two systems, with names spelt differently and minutes on one side and hours on the other, takes most of an afternoon.
What popdock provides
--
Name the project and a date range, and it totals each person's hours and billable hours on both sides, matching Teamwork.com users to Sage Intacct employees by name without pairing people on a shared first name. You get a table sorted by the largest difference, with gaps under a quarter of an hour treated as matching, and lists of people found in only one system. It says which side is higher rather than calling either wrong, and changes nothing.
Business outcome
---
You bill projects knowing every logged hour is on a timesheet, with the people who need chasing already named.
scenario
-
Account managers talking to a client want to know what work is under way and whether the client is paying. That means checking active projects and hours in Teamwork.com and the balance and aging in Sage Intacct, which rarely happens before a quick call.
What popdock provides
--
Name the client, and it finds them in both systems, carrying on with whichever side has them if the other does not. It lists active Teamwork.com projects with owners, end dates and billable hours in the last 30 days, then the Sage Intacct balance, credit limit and percentage used, and open invoices aged by due date. A one-line flag warns when billable work continues with invoices over 60 days overdue or the balance is over the limit. Nothing is changed.
Business outcome
---
Account managers go into client conversations knowing both the work in flight and the money owed.
scenario
-
When a project starts in Teamwork.com, finance still has to create a matching project in Sage Intacct before time and costs can be billed. Retyping names, dates and the client by hand invites duplicates and projects attached to the wrong customer.
What popdock provides
--
Name the Teamwork.com project and an Intacct category, and it reads the project and checks Sage Intacct for one with the same or a very similar name, stopping rather than creating a duplicate. It finds the matching Intacct customer, asks you to pick when there are several, and never creates a customer. You see the name, category, customer, dates and description, and nothing is created until you confirm. The new project is then looked up and its ID reported.
Business outcome
---
Billing projects exist in your ledger as soon as delivery starts, attached to the right customer and never duplicated.
scenario
-
When a WooCommerce shopper needs to be invoiced on account, someone sets them up in Sage Intacct by retyping their details. Without checking by email and name first, a second customer record gets created for someone already there.
What popdock provides
--
Give the shopper's email, and it reads the WooCommerce customer, or their latest order for a guest checkout, then searches Sage Intacct by contact email, billing company and name. A match only counts when the Intacct email agrees or is blank, and a different email is shown as a possible wrong match for you to judge. If the customer exists, nothing is created. Otherwise you review the values and confirm before one customer is created and read back, with the street address and country noted as left to complete.
Business outcome
---
Online shoppers become ledger customers once, with no duplicates and nothing written until you approve.
scenario
-
Orders keep shipping from WooCommerce to customers who are over their credit limit or long overdue in Sage Intacct, because nobody checks the ledger before fulfilment. By the time finance notices, the goods are gone.
What popdock provides
--
Set the order status and an overdue threshold, and it groups open WooCommerce orders by customer and finds each one in Sage Intacct by email, company or name, only accepting a match where the email agrees. Customers are flagged when their balance plus open orders exceeds the credit limit, an invoice is too far overdue, or they are inactive, with the reason shown. You choose which orders to hold; each is set on hold with a private note giving the reason, and customers never receive it.
Business outcome
---
Risky orders are paused before they ship, with the credit reason recorded on each order for your team.
scenario
-
Posting a WooCommerce order into Sage Intacct by hand means matching the shopper to a customer, mapping each product to an item by SKU and checking nobody posted it already. Skip the check and the order is billed twice; guess the customer and it lands on the wrong account.
What popdock provides
--
Name the order, and it reads the WooCommerce order and its lines, skips unpaid or canceled orders, and stops if a Sage Intacct document already carries that order number. The customer is matched by email, company or name, with a match only accepted where the email agrees, and you are asked rather than having a customer created. Each line must match one Intacct item by SKU or UPC, orders over two lines are refused, and tax, shipping and discounts are flagged as not carried. Nothing posts until you confirm, and a private order note is added only after a second yes.
Business outcome
---
Store orders reach your ledger once, on the right account, with a note on the order showing where they went.
scenario
-
Your WooCommerce catalog and Sage Intacct items are supposed to describe the same products, but SKUs go missing, discontinued items stay published and prices drift. Some stock differences are just orders waiting to ship, which makes real problems hard to separate from timing.
What popdock provides
--
Optionally name a category or warehouse, and it reads published WooCommerce products and their variations and matches each SKU to a Sage Intacct item by item ID or UPC. It lists SKUs missing or inactive in Intacct, stock and stock status differences, and prices that differ from the Intacct base price. Stock gaps that equal units on processing orders are grouped as timing only. It is read-only, lists unmatched products without SKUs, and stops if no SKU matches at all.
Business outcome
---
Your store and ledger agree on what you sell, its price and its stock, with timing noise separated from real errors.
scenario
-
Paid WooCommerce orders should all end up in Sage Intacct, but some never arrive, others carry a different total, and refunded orders sometimes stay booked at full value. Finding them means matching order numbers against invoice references across two exports.
What popdock provides
--
Give a date range, and it reads paid WooCommerce orders, marking refunded ones, and matches them to Sage Intacct invoices and order documents by order number, counting an order and its converted invoice once. You get orders missing from Intacct, totals that differ, with a note when the gap equals shipping or discounts, refunded orders booked at full value, and Intacct documents that match no order. It is read-only and says when results are partial.
Business outcome
---
Store revenue in your ledger matches what was actually sold and kept, with missing and overstated orders listed.
scenario
-
Every refund issued in WooCommerce should have a matching credit in Sage Intacct, but they are often missed or keyed for a different amount. Receivables stay overstated, and tracing refunds back through orders to invoices by hand is slow.
What popdock provides
--
Give a date range, and it reads WooCommerce refunds and their orders, finds each order's Sage Intacct invoice by order number and looks for AR adjustments against it. Refunds are compared per order, since one credit can cover several refunds. You get refunds whose order never reached Intacct, refunds with no credit, credits for a different amount, and those fully credited, with the uncredited total. Where a balance dropped without an adjustment it says the credit may have been applied another way, and nothing is changed.
Business outcome
---
Every store refund is reflected in your receivables, and the uncredited total is clear before month end.
scenario
-
When WooCommerce stock falls out of step with Sage Intacct, the store oversells items you do not have or hides items you do. Updating quantities product by product and variation by variation takes hours, and one wrong edit can switch off stock tracking.
What popdock provides
--
Name a SKU or take every stock-managed product, choose on-hand or uncommitted and optionally a warehouse, and it builds a list of WooCommerce quantities that differ from Sage Intacct. Negative quantities become zero and are flagged, and unmatched SKUs are left alone. You see every change and confirm before anything is updated, in batches of 50 for long lists. Only the stock quantity is changed, never price, status or stock tracking, and every change is read back to confirm.
Business outcome
---
Your store shows the stock you really have, updated from the ledger with every change approved first.
scenario
-
Questions about a customer's account mean checking WooCommerce for their orders and refunds and Sage Intacct for their balance, overdue invoices and payments. Completed orders that were never invoiced fall through the gap between the two.
What popdock provides
--
Give the customer's email, and it reads their WooCommerce profile, orders and refunds for the lookback period, then finds them in Sage Intacct, only accepting a match where the email agrees. You get identity details from both sides with disagreements flagged, store activity by status, and the Intacct balance, credit headroom, open and overdue invoices and recent payments. Completed orders with no Intacct invoice are called out. Currencies are kept apart and nothing is changed.
Business outcome
---
You answer customer account questions from one view, and completed orders that were never invoiced are caught.
scenario
-
Before you lean on email to chase overdue Sage Intacct customers, you need to know whether Drip can actually reach them. That means pulling overdue invoices, gathering every email on the customer and its contacts, and checking each one in Drip, where an unsubscribe quietly closes the channel.
What popdock provides
--
Set how many days overdue and a minimum balance, and it groups overdue Sage Intacct invoices by customer, collects the customer and contact emails, and checks each one in Drip. Each customer is classed as reachable, unsubscribed, not in Drip or no email on file. It is read-only and never suggests re-subscribing anyone, saying instead that unsubscribed customers need another channel. The report is sorted by overdue total, with best email and Drip tags, and totals are kept per currency rather than mixed.
Business outcome
---
Collections knows which overdue customers email can still reach and which need a call, before the next reminder goes out.
scenario
-
When a Drip subscriber becomes a paying customer, someone has to set them up in Sage Intacct with a customer record and a matching contact. Retyping the details invites mistakes, and skipping the duplicate check by email, name and customer ID leaves accounting with two records for the same buyer.
What popdock provides
--
Give the subscriber's email, and optionally a customer ID, and it reads their name, phone and location from Drip, then checks Sage Intacct for an existing contact by email, a customer or contact by name, and the customer ID. If anything matches it stops and shows you the record. Otherwise you see exactly what customer and contact will be created, and nothing is written until you say yes. The customer is created first, the contact only if that succeeds, and the stored records are read back. It tells you Drip country is not carried over.
Business outcome
---
New buyers reach Sage Intacct once, with a matching contact and no duplicate customers for accounting to merge.
scenario
-
Account reviews need both sides of a customer: how their people engage with your Drip emails and how the account bills and pays in Sage Intacct. Pulling that together means finding every contact email, looking each up in Drip, then reading a year of invoices and payments separately.
What popdock provides
--
Name a Sage Intacct customer by ID or name and it gathers the customer and contact emails, looks each one up in Drip for status, lead score, tags, lifetime value and campaigns, and reads the last 12 months of invoices and payments. It is read-only. You get a header with terms, credit limit and balance, a people table, a billing summary with open invoices and oldest due date, and a short note on what stands out. Drip lifetime value and invoiced totals are shown side by side, not reconciled.
Business outcome
---
You walk into an account review knowing both how a customer engages and how they pay.
scenario
-
Enrolling Sage Intacct customers in a Drip email series means exporting active customers, gathering contact emails, cleaning out blanks and duplicates, and checking each against Drip. Miss a step and you either enrol someone who unsubscribed or add the same person to the campaign twice.
What popdock provides
--
Name the Drip campaign, and optionally a customer type and state, and it selects active Sage Intacct customers, collects their customer and contact emails, and drops blanks, invalid addresses and duplicates. Each email is checked in Drip: unsubscribed people are never enrolled, even if you ask for everyone, and people already in the campaign are skipped. You see every action, including how many people Drip will create as new subscribers, and nothing is written until you say yes. Afterwards it confirms each person appears in the campaign.
Business outcome
---
Customer campaigns reach the right Sage Intacct contacts without enrolling anyone who opted out or doubling up.
scenario
-
Marketing wants to know which Drip subscribers are already paying customers and which are still leads, but customer status lives in Sage Intacct. Matching by hand is slow, and names, phone numbers and states drift apart between the two systems without anyone noticing.
What popdock provides
--
Optionally give a tag or a start date, and it reads Drip subscribers, finds each email among Sage Intacct contacts, and checks the linked customer. Each subscriber is classed as customer, inactive customer, contact without customer, or lead only. Nothing is changed in either system. For every match it compares first and last name, phone by digits only and state, treating codes and full names as equal, and lists the differences. Emails shared by several Sage Intacct contacts are flagged as duplicates.
Business outcome
---
You see exactly who on your Drip list is a customer, lapsed customer or lead, and where the records disagree.
scenario
-
Promotional emails to customers with unpaid Sage Intacct invoices can land badly, yet Drip has no idea who is overdue. Tagging those people by hand means pulling overdue invoices, finding every customer and contact email, and checking each subscriber's tags in Drip.
What popdock provides
--
Set a tag and how many days overdue, and it groups overdue Sage Intacct invoices by customer, collects the customer and contact emails, and checks each one in Drip. Existing subscribers without the tag are marked to tag, people not in Drip are skipped and never created, and unsubscribed people are flagged. You see the full table and nothing is tagged until you say yes. Each tag is then verified on the subscriber. It reminds you that removing the tag once customers pay is a separate task.
Business outcome
---
Drip automations can exclude or chase overdue customers, with no new subscribers created along the way.
scenario
-
After a Drip email series runs, leadership asks whether it led to sales. Answering means matching campaign subscribers to Sage Intacct customers, then pulling each customer's orders and invoices since the launch, a manual exercise that easily double counts customers with several people in the campaign.
What popdock provides
--
Name a Drip campaign and an optional start date, and it lists the campaign's subscribers, matches each email to a Sage Intacct contact and customer, and reads orders and invoices since the campaign was created. It is read-only. You get the campaign summary, a funnel from subscribers to customers who bought, and a table per customer, with each customer counted once and totals kept per currency. The report states plainly that this shows correlation, not attribution.
Business outcome
---
You see what campaign recipients went on to order and pay for, without overstating what the campaign caused.
scenario
-
Posting a Ramp card transaction into Intacct by hand means looking up the transaction, checking whether someone already booked it, confirming the GL account is open, and keying the charge card entry. Miss the duplicate check or pick a closed account and the ledger carries a double posting or a failed entry that someone has to unwind later.
What popdock provides
--
Give a Ramp transaction id and the GL account to post to, and it reads the transaction from Ramp and stops if it is missing or declined. It then checks Intacct for an entry with the same payee, date and amount, and confirms the GL account exists and is active. You see the payee, amount, currency, date, charge card and account, and nothing is written until you say yes. It creates the charge card transaction once, never retries on failure, and reads the stored record back. The Intacct write has not been individually tested, so try it in a test company first.
Business outcome
---
Ramp card transactions are booked in Intacct once, to a valid GL account, with a read-back as proof and no duplicates to reverse.
scenario
-
Ramp GL accounts have to line up with the Intacct chart of accounts, but the two are maintained separately. A code that was never created, a closed account, or one that blocks direct posting only shows up when a sync fails, usually during close.
What popdock provides
--
Name a filter, or leave it empty for everything, and it reads the active GL accounts in Ramp and the matching accounts in Intacct. It matches them by account code, ignoring padding and leading zeros, and sorts each into matched, no Intacct account, inactive in Intacct, direct posting disallowed, or titles that differ materially. The report is grouped by verdict with problems first and counts. Nothing is changed in either system. With no filter it reads up to the record limit and tells you the list may be cut short.
Business outcome
---
Broken account mappings are found and listed before a sync fails, so you can fix them in Ramp or Intacct on your own schedule.
scenario
-
Vendors get added to Ramp and Intacct by different people at different times. Names are spelled differently, one side is marked inactive, or the country does not agree, and nobody notices until a payment fails or a bill will not post.
What popdock provides
--
Give a vendor name, and optionally how many to check, and it reads the matching vendors in Ramp, then looks each one up in Intacct. You get one row per Ramp vendor showing the Intacct vendor id or missing, status on both sides, country on both sides, and a verdict: match, missing in Intacct, inactive mismatch, country mismatch or ambiguous. Names that differ only by case, punctuation or a suffix such as Inc or LLC count as the same. Nothing is created or changed in either system.
Business outcome
---
Vendor gaps between Ramp and Intacct are caught in one read, before a payment or a bill runs into them.
scenario
-
Setting up in Intacct a vendor that already exists in Ramp means re-keying the name, choosing an id, and first checking that no similar vendor is already there. A typo or a skipped search leaves a duplicate vendor that later splits bills and payments.
What popdock provides
--
Name the Ramp vendor, and optionally the Intacct vendor id to use, and it reads the vendor from Ramp, stopping if several match or it is inactive. It then searches Intacct for a vendor that looks the same and stops if it finds one. You see the vendor id, name and print as value, and nothing is written until you say yes. It creates the vendor once, never retries on failure, and reads the stored vendor back. The Intacct write has not been individually tested, so try it in a test company first.
Business outcome
---
New Intacct vendors match their Ramp record, are created once without duplicates, and come with a read-back to confirm what was stored.
scenario
-
Reconciling one vendor's bills between Ramp and Intacct means pulling both lists, lining up invoice numbers that differ in case or leading zeros, and comparing amounts, due dates and payment state by eye. Bills that exist on one side only, or that disagree, are easy to miss.
What popdock provides
--
Give a vendor name, and optionally how many days back to look (the default is 60), and it reads that vendor's bills from Ramp and Intacct. It matches them on invoice number, ignoring case and leading zeros, then compares amount, due date and payment state. You get three lists: bills in Ramp only, bills in Intacct only, and matched bills that differ with both values shown, ending with counts and the amount at stake. Currency mismatches are reported rather than compared, it stops if either side has no bills, and nothing is changed.
Business outcome
---
Every billing difference for a vendor between Ramp and Intacct is listed with both values, so you fix the right bills and nothing is guessed.
scenario
-
At month end every Ramp card transaction has to be matched to an Intacct charge card entry by hand, comparing amount, date and merchant across two screens. Entries that never made it across, or made it across with the wrong amount, are easy to miss in a long list.
What popdock provides
--
Give a start and end date, and optionally some merchant text, and it reads the Ramp card transactions and the Intacct charge card transactions for that period. It matches them one to one on amount, a date within 3 days and a similar merchant and payee. You get Ramp transactions with no Intacct entry, flagging any that Ramp says are synced, Intacct entries with no Ramp transaction, and amount mismatches, with counts and totals. Nothing is created or changed in either system.
Business outcome
---
Month-end card spend is matched in minutes, and the unmatched items are listed so you chase only the ones that matter.
scenario
-
Checking whether an employee's Ramp reimbursements made it into Intacct means finding the person in both systems, then comparing each reimbursement with Intacct reimbursements and expense reports by amount and date. Items on one side only, or paid in one place and not the other, are hard to spot.
What popdock provides
--
Give an employee id and a start date, and it finds the employee in Ramp, reads their reimbursements, then reads their Intacct reimbursements and expense reports. It matches by amount with dates within 7 days and reports items in Ramp only, items in Intacct only, and matched items whose payment status disagrees, ending with totals per side and the difference. Currency differences are reported rather than compared. If the employee is missing from Intacct it says so and still lists the Ramp items. Nothing is added or changed.
Business outcome
---
Reimbursement gaps between Ramp and Intacct for an employee are listed with totals, so nobody is left unpaid or paid twice.
scenario
-
Checking one Intacct invoice against its Avalara AvaTax tax calculation means opening two systems and comparing the numbers by hand. Mismatches in amount, customer or currency go unseen until someone audits.
What popdock provides
--
Name an invoice and it reads the Intacct invoice, finds the AvaTax transaction with the same number and compares date, customer, currency and amount. It stops if the invoice is ambiguous or no AvaTax transaction exists. Intacct and AvaTax are only read, never changed.
Business outcome
---
An invoice and its AvaTax transaction are compared in one answer, so mismatches are caught before filing.
scenario
-
Customers in states with no registered nexus are easy to miss when you compare an Intacct customer list with Avalara AvaTax registrations by hand, and the gap shows up only when a state asks questions.
What popdock provides
--
It groups Intacct customers by state and compares the states with the nexus recorded in Avalara AvaTax. It flags states that have customers but no nexus. The output is a review list and not a finding of tax owed. Intacct and AvaTax are only read, never changed.
Business outcome
---
States with customers but no recorded nexus are listed for review, with nothing changed in either system.
scenario
-
Vendor bills with no Avalara AvaTax purchase record can hide use tax that nobody assessed. Nobody checks the bills against AvaTax by hand, so the gap stays hidden.
What popdock provides
--
Give a date range and it lists Intacct bills in that range that have no AvaTax purchase transaction. It warns when results may be incomplete or when no purchases run through AvaTax at all. Intacct create and update actions and AvaTax action tools are never used, and nothing is changed.
Business outcome
---
Bills with no AvaTax purchase record are found so unassessed use tax can be reviewed, with nothing changed in either system.
scenario
-
Invoices that never reached Avalara AvaTax mean sales tax that is never reported. Finding them by hand across two systems is slow and error prone.
What popdock provides
--
Give a date range and it lists Intacct invoices in that range that have no matching AvaTax transaction. It stops if either side returns nothing and warns when the results hit the record cap. Intacct create and update actions and AvaTax action tools are never used, and nothing is changed.
Business outcome
---
Invoices that never reached AvaTax are found before the sales tax goes unreported, with nothing changed in either system.
scenario
-
Someone compares the Intacct customer list with the Avalara AvaTax customer list by hand. Customers missing from AvaTax get no tax or exemption handling, and nobody notices until a sale is taxed wrongly.
What popdock provides
--
It matches Intacct customers to AvaTax customers by customer code and reports customers that are missing from AvaTax and ones whose details differ. Weak name matches are flagged and inactive customers are listed separately. Intacct create and update actions and AvaTax action tools are never used, and nothing is changed.
Business outcome
---
Customers missing from AvaTax are found before they are taxed without exemption handling, with nothing changed in either system.
scenario
-
Items without an Avalara AvaTax tax code are taxed wrongly. Comparing the Intacct item catalog with the AvaTax catalog by hand misses gaps.
What popdock provides
--
It matches Intacct items to AvaTax items by item code or UPC and reports items missing from AvaTax and items with no tax code. Inactive items are separated from the rest. Intacct create and update actions and AvaTax action tools are never used, and nothing is changed.
Business outcome
---
Items with no AvaTax tax code are found before they are taxed wrongly, with nothing changed in either system.
scenario
-
Vendor lists in Intacct and Avalara AvaTax are compared by hand and drift apart. Purchases then lack the vendor tax details they need.
What popdock provides
--
It matches Intacct vendors to AvaTax vendors by vendor code and reports vendors that are absent from AvaTax and ones that differ. Weak matches are flagged and vendors lacking data are marked unverifiable. Intacct create and update actions and AvaTax action tools are never used, and nothing is changed.
Business outcome
---
Vendors missing from AvaTax or lacking data are found before purchases need their tax details, with nothing changed.
scenario
-
Subscription revenue in the billing system and recurring invoice schedules in the ledger drift apart unnoticed. Comparing them means reading active Chargebee subscriptions, finding the customer in Intacct and normalising amounts to a monthly figure by hand.
What popdock provides
--
Give a Chargebee customer id and it reads their active subscriptions and company name from Chargebee. It finds the Intacct customer by id or by company name and reads their active recurring invoices. It compares the combined Chargebee MRR with the Intacct amounts normalised to monthly, and reports subscriptions with no recurring invoice, schedules with no active subscription and differences in amount or frequency. An empty Intacct result is treated as no recurring schedule, not an error, and nothing is written to either system.
Business outcome
---
Finance sees where subscription revenue and ledger schedules disagree, without mistaking a missing schedule for a system error.
scenario
-
New billing customers are re-keyed into the ledger by hand, and some are never created while others are created twice. Finding the missing ones means listing recent Chargebee customers and searching Intacct for each by name and by email.
What popdock provides
--
Give a look-back period, or use the last 30 days, and it lists the Chargebee customers created in that window. For each it searches Intacct by company name and by contact email and treats a customer with no hit from either as missing. It lists the missing customers with the values that would be sent and asks which ones to create. Possible matches with a different spelling are listed separately and never offered for creation. Only after a clear yes does it create the confirmed customers, read each back to confirm it, and it writes nothing to Chargebee.
Business outcome
---
Only genuinely missing customers are created in Intacct, each one confirmed by you and checked afterwards.
scenario
-
Staff search Intacct by hand for the customer behind a Chargebee account and sometimes pick the wrong near duplicate. Names differ by Inc or LLC, and nothing tells them how confident the match is.
What popdock provides
--
Give a Chargebee customer id, email or company name, and it finds the customer in Chargebee, stopping with a list if several match. It then searches Intacct by company name, or by an Intacct customer id if you supply one, and checks whether a contact carries the same email. If several Intacct customers come back it ranks the top three by name, city and state. You see both records side by side with their open balances and a verdict of exact match, probable match or no match. It never calls a name only match certain and creates or changes nothing in Intacct.
Business outcome
---
Finance links the right Intacct customer to a Chargebee account with a stated level of confidence, not a guess.
scenario
-
Credit notes issued in billing are not always booked as adjustments in the ledger, so revenue is overstated. Checking means listing credit notes, resolving each customer in Intacct and searching for a matching adjustment by hand.
What popdock provides
--
Give a look-back period, or use the last 30 days, and optionally one customer, and it lists the Chargebee credit notes in that window. It resolves each customer in Intacct by company name and looks for a customer adjustment from the same date, matching on the referenced invoice number where it can. You get a table per credit note showing the matching Intacct adjustment and amount or missing in Intacct, with the missing ones first and totals of missing and mismatched amounts per currency. Customers it cannot match are listed separately, and nothing is written.
Business outcome
---
Finance sees which credit notes are missing from the ledger and the amount at stake, per currency.
scenario
-
Month end reconciliation of billing against the ledger is done in spreadsheets and misses invoices or amount differences. Someone has to list invoices from both systems for a customer and match them by number, total and date.
What popdock provides
--
Give a Chargebee customer id, and optionally a look-back period and Intacct customer id, and it reads the Chargebee invoices and the company name. It resolves the Intacct customer, stopping with a list of candidates if it is ambiguous, and reads their Intacct invoices. It matches by invoice number, then by identical total within three days, flagging those amount and date matches as lower confidence. You get invoices in Chargebee only, in Intacct only and matched with a different total or paid status, ending with counts and the net difference per currency. It never changes Intacct.
Business outcome
---
Finance sees every invoice that is missing or different between billing and the ledger, with match confidence stated.
scenario
-
Cash application means checking the gateway payment in Chargebee, then hunting for the receipt and the invoice in the ledger. Payments can be batched into deposits, which makes a simple trace take many searches.
What popdock provides
--
Give a Chargebee payment or invoice reference and it finds the payment, its customer, amount, date, status, gateway and payment method. It resolves the Intacct customer and looks for a receipt with the same amount in a window around the payment date, and if none matches it looks for a batched deposit. It then checks the Intacct invoice is consistent with the payment being applied. You get one verdict: received and applied, received but not applied, deposited in a batch, or not found. It lists every candidate receipt rather than choosing, and failed or refunded payments are not expected in Intacct.
Business outcome
---
Finance can say whether a Chargebee payment reached Intacct and was applied to the right invoice, with dates and amounts side by side.
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.