External Sales Accounting

What it is for

If you invoice from an external point of sale that signs through Polaris, those sales exist before DGII but not in your books. This integration closes that gap with no data entry: every four hours AdmCloud checks which new documents DGII accepted and registers them; overnight it groups what was registered by issue date and creates each day's journal entry.

The integration feeds revenue and taxes. It does not move inventory, does not compute cost of sales and does not create the customer receivables subledger: every sale is treated as a cash sale against an offset account of your choosing.

Before you start

• Your company must have electronic invoicing enabled with Polaris as the gateway and its token already configured. This screen reuses that configuration and does not ask for the token again.
• The company's functional currency must be the Dominican peso, because fiscal document amounts come in pesos.
• You need the accounts you are going to map already created.
• If your company uses subsidiaries, you must have signed in with a subsidiary selected. The configuration and the log belong to a subsidiary; if your user group signed in without choosing one, both screens will not let you in.
• The tax ID of the company or subsidiary must match the one on the Polaris token. AdmCloud does not ask the company record which issuer's documents to read: it asks the token, which Polaris issued for your company and cannot be substituted. The company record is used only as a cross-check. If the two do not match, the integration stops and the message shows both tax IDs, so you can fix the company record or check which token is configured.

Configuration

Go to Fiscal → External sales accounting setup. The screen has three blocks.

General

• Enabled. Turns the integration on for the subsidiary you are in. While off, nothing is brought in and nothing is posted.
• Bring from. Documents issued before this date are not brought in. Use it so you do not create entries for months you already accounted for another way. Defaults to today.

Document types are not configurable: every type that affects sales is posted, and the screen shows them for reference. The three purchase documents are excluded, because they are issued by the payer and not the seller: purchase voucher (informal suppliers), minor expenses and foreign payments.

The current day is not configurable either: it is always left for the next run, so each day results in a single journal entry instead of being split in two.

Accounts

Each concept of the document goes to the account you set here. Required ones are the offset account, taxable income at rate 1, exempt income and sales tax at rate 1; the rest are only needed if they show up in your documents.

It helps to tell income accounts apart from tax accounts, because the names look alike:

• Taxable income rate 1, 2 and 3. These are income accounts: the sale itself, without the tax. DGII defines three rates -18%, 16% and 0%- and the document carries the amount sold under each one.
• Exempt income. Also income. The sale is exempt from tax, but the amount sold exists and has to be recorded. Without this account, a document with exempt lines is left in error because its entry would not balance.
• Sales tax payable rate 1 and 2. These are the tax accounts: what you charged the customer and owe to DGII.

No tax account is requested for rate 3, because DGII sets that rate at 0%: the tax is always zero and the account would never be used. The taxable income rate 3 account is still needed, because the sale does have an amount even though it carries no tax.

The document's amounts come net of discount. AdmCloud records gross revenue and books the discount to the Sales discounts account, so it is visible on its own instead of hidden inside revenue. The entry still balances: the same amount is added to both sides.

Both places where a document can declare a discount are covered: the line discount -"this item gets 10% off"- and the global discount -"10% off the whole invoice"-. Each one is credited back to the kind of sale it belongs to, so a discount on an exempt sale does not pollute taxable revenue.

Example: an item of 1,000 with a 100 line discount and a 50 global discount. The document declares 850 of taxable sales, 153 of tax and 1,003 as the total. The journal entry records 1,000 of revenue, 150 of discount, 153 of tax payable and 1,003 in the offset account.

Surcharges are not recorded separately. Unlike a discount, a surcharge already comes added into the sale amount, so counting it again would double it.

The offset account is the only debit account and receives what the customer paid: taxable plus exempt plus taxes, less any withholdings. A clearing account usually works better than cash, because the point of sale's actual deposits, net of card fees for instance, do not come in through this integration.

Only the additional taxes already seen in your documents are offered, plus the legal tip. If one arrives with a tax you had not mapped, that document is left in error stating which account is missing, and the tax shows up on this screen the next time you open it.

Notifications

EMail notification decides when you are told about the posting result. The run happens either way with any of the three options: this only changes whether an EMail is also sent. The full result is always recorded in the log.

• Do not notify. No EMail is sent. You have to open the log to find out about a problem. It makes sense when someone already reviews accounting daily.
• Only when there are problems. An EMail arrives only if the run left documents in error or blocked by a closed period; nothing arrives when everything went well. This is the recommended option: a daily EMail that always says the same thing stops being read, and this one only arrives when there is something to do.
• Summary of every run. One EMail per posting run, with or without problems, listing the journal entries created and the document counts. Useful for the first few days, to confirm the integration is working; after that it is usually worth switching to the previous option.

Notification EMails takes the recipients separated by commas. If you pick Do not notify this field is not used; with either of the other two options it is required, because a notice with no recipient reaches nobody and nobody finds out it is missing.

Reading documents from Polaris, which runs every 4 hours, notifies separately when it leaves documents with an error -one whose XML could not be read, for example- or when the reading itself is interrupted. That notice arrives with either of the two options that notify, and only when there is something to attend to: a summary of every pass would be 6 EMails a day of noise.

Log

The history has two tabs. You reach it from the menu, with External sales accounting log, or from the button on this screen. They are separate menu entries on purpose: setup is touched once and the log is checked daily.

Documents

One row per fiscal document, with its status and, once posted, the number of the journal entry that covers it. Because the entry is summarized and does not carry the document numbers, this screen is how you find out what makes up an entry: copy the entry number and paste it into the Journal entry filter.

Two columns are links. The e-NCF opens the DGII stamp lookup for that document, which is how you confirm with DGII that it exists and how they received it; it opens in another tab. The Journal entry opens the entry that posts the document. The e-NCF has no link when the document was registered before AdmCloud started storing it, or when the gateway did not return it.

The last column, Action, only shows a button on documents that can be reprocessed: the ones left with an error or blocked by a closed period. If it is empty on every row, there is nothing to retry.

Runs

The execution history, showing how many documents were read, registered and skipped, and how many journal entries were created. Process tells the two stages apart: Sweep reads the documents from Polaris and Posting creates the journal entries. Start is shown in your user's time zone, not the server's.

Status is the run’s own, not the documents’:

• Running. Still working.
• Completed. It reached the end. Finishing does not mean everything was posted: the With errors column says how many documents need attention.
• Interrupted. It fell over before finishing and the reason shows in Detail. That is all that column shows: the failure of one document is on the Documents tab.

Document statuses

Not every document ends in an entry, and not every one that does not is an error.

• Pending signature. Legacy status: no longer used. A document DGII has not accepted yet does not enter the log; AdmCloud picks it up on the run right after it is accepted, so a document waiting for days is not lost.
• Pending posting. Accepted by DGII and waiting for the next posting run.
• Posted. Already part of a journal entry.
• Issued from AdmCloud. AdmCloud issued that invoice, so it already has its own accounting and is not posted again.
• Closed period. Its issue date falls in a closed accounting period. The date is not moved: it stays blocked until you reopen the period and reprocess it.
• Rejected by DGII. It is not a valid sale and is not posted.
• Error. Posting failed. The detail column says exactly why: a missing account, amounts that do not add up, and so on.

Reprocessing a document

Documents in error or blocked by a closed period have a Reprocess button that sets them back to pending so the next run tries again. Use it after fixing whatever caused the problem: adding the missing account, reopening the period, and so on.

A document already posted cannot be reprocessed, because it would create a second entry for the same sale.

Frequently asked questions

I issued an invoice today dated last week. What happens?

It comes in normally and creates its own journal entry, dated last week. The entry that already existed for that day is not touched. If that period is closed, the document is blocked and you are told.

Will the invoices I issue from AdmCloud be duplicated?

No. AdmCloud recognizes the documents it issued and marks them as Issued from AdmCloud without posting them, because those invoices already have their own accounting.

Why does one day have two journal entries?

Because documents for that day arrived after it was posted. Late arrivals do not modify the original entry: they create an independent entry dated on the same day. That keeps the books auditable and never rewrites an entry already posted.

A document's total does not add up and it was left in error. What do I do?

That document came in malformed from the system that issued it: its total does not match the sum of its components. AdmCloud rejects it rather than forcing the balance with an adjustment account, so your books stay clean. It has to be fixed at the source, usually with a credit note.