Skip to main content

​
Acumatica

Monk follows up on overdue Acumatica invoices and keeps customer replies, payment promises, and collection history together. Your team can see who has promised to pay and which conversations need attention. You continue to issue invoices in Acumatica, and Monk refreshes from it every hour. By default the connection is read-only. With payment push switched on, a payment recorded in Monk is also posted to Acumatica and applied to the invoice it pays.

​
How it works in practice

A customer receives a reminder for one overdue invoice and replies with a payment date. Monk records the promised date and pauses reminders based on your team’s settings. A colleague can see the commitment alongside the invoice without searching the inbox. Once your team records full payment in Acumatica, the next completed sync marks the invoice as paid in Monk and stops reminders for it. If the customer disputes the invoice, Monk pauses reminders and flags the conversation for review.

​
What stays in Acumatica and what happens in Monk

Acumatica lets you configure dunning levels by customer class. If your team also tracks payment promises and follow-up dates in inboxes or spreadsheets, Monk keeps those commitments and customer replies alongside the relevant invoices. Credit limits, payment terms, and credit holds stay in Acumatica, along with the general ledger, month-end close, and statutory reporting. Monk reports aging and DSO for the invoices it imports. Reminders go to the contacts already on the Acumatica customer account: every active contact with an email address, plus the account email when no contact carries it. Recipients are reviewed with you during onboarding.

​
Requirements and scope

  • Acumatica 2025 R2 or later, Acumatica-hosted or self-hosted, reachable over public HTTPS. Monk reads the Default endpoint at version 25.200.001, which 2025 R2 and later builds publish. To check, open Web Service Endpoints (SM207060) or https://<your-site>/entity and look for Default at 25.200.001.
  • One tenant, one company, one branch per Monk org. The tenant is part of the client ID. What Monk reads is decided by the dedicated user’s company and branch access plus restriction groups in Acumatica; the Branch setting in Monk does not narrow it. For a single-company pilot, restrict that user to the pilot company and its approved branches before authorizing Monk. Confirm that the user can select only that company in Acumatica. Records outside its access are left out without an error, so if receivables sit across several companies or branches, agree the setup with your Monk contact.
  • Single currency. Monk currently supports tenants that invoice in one currency, matching your Monk organization’s currency. Multi-currency support is planned. If your tenant invoices in multiple currencies, talk to your Monk representative about your requirements.
  • Hourly refresh, plus on demand. Monk reads what changed since the last run every hour, and Refresh now starts a run immediately. Reminders use the balance from the latest refresh, so after posting a large batch of payments, refresh before reminders go out.
  • History. The first refresh reads customers, contacts, credit memos, payments, and applications in full, and invoices changed in the last 12 months. The import start date agreed during onboarding decides which of those become invoices in Monk.
  • One API user licence slot. Monk signs in as a dedicated Acumatica user, which holds one API user slot while connected.
  • Customer hierarchy. Monk reads the Parent Account on a customer and links the child to its parent once both exist in Monk. Reminders go to each customer’s own contacts, parent or child.

​
Setting up Acumatica

Setup is done together with Monk. Steps 1 and 2 use standard Acumatica forms and need no customization project or installed component. Connecting, the first sync, checking the imported invoices against Acumatica, and switching on invoice import and follow-ups are done with a Monk engineer. Agree the import start date and the refresh-token setting with your Monk contact before you register the Connected Application.
Steps 1 and 2 are done by your Acumatica administrator; step 3 by a Monk user who can manage integrations. Before you start, open Integrations → Acumatica in Monk and copy the Redirect URI shown there; step 2 needs it.
1

Create a restricted role and dedicated user

Create a role on User Roles (SM201005), for example MONK-API-READ. In Access Rights by Screen (SM201020), set each of the following actual forms to View Only and leave every other form revoked:
  • Customers (AR303000), under Receivables
  • Invoices and Memos (AR301000), under Receivables
  • Payments and Applications (AR302000), under Receivables
  • Contacts (CR302000), under Marketing
Acumatica permissions for Customers, Invoices and Memos, and Payments and Applications set to View Only

Desired permission outcome: three Receivables forms set to View Only, everything else revoked. Contacts (CR302000) is set the same way under Marketing.

If you will use payment push, set Payments and Applications (AR302000) to Delete instead of View Only. Monk creates, releases, voids, and deletes the payments it pushes, and a View Only user is refused. The user must also have access to the branch that pushed payments post to.On Users (SM201010), create a dedicated user with only that role. For a single-company pilot, use your Acumatica company/branch access and restriction-group configuration to limit this user to the pilot company and its approved branches. Sign in as this user and confirm the company picker exposes only that company before you connect Monk. It signs in to a browser once, during consent, so it must be a regular user rather than Acumatica’s API-only user type. Check License Monitoring Console (SM604000) for a free API user slot if other integrations already use the API. If the user later loses access to one of these forms, refreshes stop at that read until access is restored.
2

Register the Connected Application

On Connected Applications (SM303010):
  • Set Flow to Authorization Code.
  • On the Redirect URIs tab, paste the redirect URI copied from Monk.
  • On the Secrets tab, add a Shared Secret and copy it when it is shown; Acumatica does not display it again.
  • Under Refresh Tokens, choose a mode other than No Refresh Tokens. With sliding expiration the connection stays alive while Monk keeps syncing, up to any absolute cap you set; with absolute expiration an administrator re-authorizes on that schedule.
  • Save. Acumatica generates the client ID as <GUID>@<Tenant>, for example 0A1B2C3D-4E5F-6789-ABCD-EF0123456789@LIVE, where the suffix is the tenant you were signed in to. Monk needs the whole value. Your Acumatica username is not the client ID.
Acumatica Connected Applications screen with the Authorization Code flow and a shared secret

Flow set to Authorization Code and one shared secret added. The redirect URI lives on the Redirect URIs tab next to Secrets.

3

Connect in Monk and approve access

In Integrations → Acumatica, enter the instance URL, the full client ID, and the client secret, then click Save and authorize. The instance URL is the site root only, for example https://erp.example.com/Instance or https://yourcompany.acumatica.com. Do not enter a screen URL or an identity URL such as https://yourcompany.acumatica.com/t/live/identity; Acumatica’s Client Application Access page lists those identity addresses, but Monk builds them from the site root. Monk sends you to your instance: sign in as the dedicated user (sign out of Acumatica first, or use a private window) and approve the two permissions, Access to Web Services API and Offline Access.The authorization link expires after ten minutes and is bound to the Monk user who started it. If it expires, click Authorize in Acumatica on the Monk page to try again. If the user’s Acumatica role changes after Monk is connected, click Reauthorize in Acumatica to issue a fresh grant; your Acumatica settings and shared secret are unaffected.The Branch field under Instance settings does not limit what Monk reads: the dedicated user’s branch access and restriction groups decide that. If you set a branch, choose one the dedicated user can access; otherwise reads fail with an error. Set the branch right after connecting, before the first refresh. Once data has synced, the branch is fixed.

​
Supported entities

​
How Acumatica documents map to Monk

Each sync records the payments, credit memos, and write-offs applied to invoices already in Monk. Their balances reflect those applications. When Acumatica shows an invoice closed or with a zero balance, Monk marks it paid.
Monk customer page showing recent activity entries for credits applied, payments allocated, and an invoice paid from Acumatica

A customer in Monk after a refresh: each Acumatica application arrives as a credit applied, a payment allocated, or an invoice paid.

​
Authentication and connection

  • Your Acumatica administrator registers a Connected Application (SM303010) with the Authorization Code flow. Monk requests two scopes, shown on the consent screen as Access to Web Services API and Offline Access, and acts as the Acumatica user who approves them.
  • Monk stores your instance URL, tenant, client ID, shared secret, and the access and refresh tokens encrypted at rest, and rotates refresh tokens automatically.
  • The instance address is validated when you connect and each time Monk requests a token: public HTTPS only, no private or internal hosts. Reads use the validated address and never follow a redirect to another host.
  • If the grant is revoked or a token refresh is refused, the connection shows Authorization needed with an Authorize in Acumatica button. To be emailed when that happens, turn on Integration reconnect required under Settings → Notifications in Monk and add recipients.
  • To revoke access at the source, open the Connected Application in Acumatica and click Revoke Access, which removes the tokens Monk holds, and delete its shared secret so no new token can be requested.
  • Disconnect in Monk stops reads and archives the connection with its settings so the same instance can be reconnected later. Imported customers and invoices stay in Monk with the balances from the last refresh, and nothing is revoked inside Acumatica. Disconnect does not by itself stop follow-ups on those invoices, so ask your Monk contact to switch off follow-ups at the same time.

​
Configuration and sync

  • Instance and tenant: your Acumatica site URL and Connected Application credentials.
  • Endpoint version: leave blank. Monk reads the Default endpoint at version 25.200.001, which Acumatica 2025 R2 and later builds publish, and the integration is validated against that version. If Web Service Endpoints (SM207060) shows Default at another version, talk to your Monk contact before connecting.
  • Branch: leave blank. It does not limit what Monk reads, which the dedicated user’s branch access and restriction groups decide, and a branch that user cannot access makes reads fail with an error. Fixed once data has synced.
  • Licence tier: leave blank unless you are sure of it. Blank means Monk reads at its slowest pace, one request at a time and at most 50 a minute. Acumatica enforces its per-minute API limit by delaying requests, so a tier set higher than your licence allows shows up as slower screens for your own users rather than as an error in Monk. Set it to the tier shown in License Monitoring Console (SM604000) only when you want the first read to go faster.
  • Import start date, automatic import, and follow-ups: how far back Monk imports invoices, whether new documents import automatically, and whether Monk follows up on Acumatica invoices at all. All three are switched on with your Monk contact during onboarding, and off the same way. Invoices and their payments are imported together, so a partially paid invoice never appears with its full balance.
  • Refresh behavior: a truncated or malformed response from Acumatica fails the refresh instead of importing an empty page, so a bad read never overwrites correct balances. A daily check calls your instance with the stored grant, so a revoked grant or an instance Monk cannot read is reported as Authorization needed and emailed to the recipients you set. Refresh now reports that a refresh started; a first refresh can take several minutes.

​
Payment push

Payment push is optional and off by default. When it is on and a payment is applied to invoices in Monk, Monk creates a payment in Acumatica, applies it to the same invoices, and releases it. If that payment is later reapplied or moved back to review in Monk, Monk voids the Acumatica payment and, for a reapply, pushes a new one.
  • Before switching it on: give the dedicated user Delete access to Payments and Applications (AR302000) and access to the posting branch (see step 1). Then choose the payment method and cash account on the Payment Posting card in Integrations → Acumatica. The branch is taken from the cash account you pick.
  • Switching it on: Auto-push payments to Acumatica is turned on and off with your Monk contact, like automatic import.
  • No duplicates: each pushed payment carries a Monk reference in its external reference field, and Monk checks for it before creating a payment, so a retry never posts the same payment twice.
  • Credit verification can block a void. If the customer is over their credit limit or days-past-due threshold, Acumatica refuses the void. Monk retries, then queues the void for your Monk contact to resolve with you. It never changes your credit settings to force the void through.

​
Frequently asked questions

How do our customers pay? They keep using your existing payment methods. Monk reminders include a PDF copy of the invoice but no payment link. Your team records payments in Acumatica as usual, or in Monk with payment push switched on. Can we keep sending Acumatica dunning letters while we use Monk? You can, but the two do not know about each other. Prepare Dunning Letters (AR521000) reads Acumatica and Monk sends its own reminders on its own schedule, so a customer covered by both receives both. When piloting, choose the customers Monk follows up on and exclude them from your Acumatica dunning run. Do credit limits, credit holds, or customer classes affect what Monk sends? An invoice on credit hold is not imported until it is released. Credit limits and customer classes stay in Acumatica; you configure each customer’s reminder sequence in Monk. Can we test the integration in an Acumatica sandbox before connecting production? Yes. You can test the integration in an Acumatica sandbox before connecting production. Let your Monk representative know before you start so we can plan both connections and validate the workflows you need. Production requires a new connection, and any data imported from the sandbox stays in Monk. Planning ahead helps us keep test data separate from your production receivables.