# DALI user manual DALI is audit data analytics without the data science. You bring in the file you already have, answer two or three plain-English questions, and get your exceptions, with every step logged so a reviewer can reproduce the result years later. This manual is also available inside DALI: it is the last item on the left, **User manual**. ## What DALI is - **A desktop program.** Everything runs on your own computer. Nothing is uploaded anywhere, and DALI does not need an internet connection. - **One file per project.** A project is a single `.dali` file holding your datasets, every result, your routines, and the log. Copy it, back it up, or hand it to a reviewer like any other file. - **An audit trail of the analysis itself.** Every test and every preparation step is recorded with its settings and the exact SQL that produced it. - **Built for size.** A one-million-row file imports in seconds and runs the whole suite of tests in under a minute on an ordinary laptop. The left menu is the map: **Home**, **Data**, **Databases**, **Prepare**, **Analytics**, **Schedules**, **Results**, **Export**, and this manual. ## Start here Your first ten minutes: 1. Click **New project**, give it a name, and save it. Projects go under `Documents\DALI Projects` unless you choose somewhere else. 2. On **Data**, click **Add a data file** and pick a CSV, text file or Excel workbook. DALI reads the layout, keeps every row, and shows a profile with control totals you can tie back to the source system. 3. Open **Analytics**, pick a test across the top (start with **Find duplicates**), choose the dataset and the columns, and click **Run**. 4. The result opens as a grid. **Export to Excel** puts it in a workbook with an "About this test" sheet carrying the settings and the SQL. Everything you ran is listed under **Results**, newest first. ## Projects - **New project** creates an empty `.dali` file. **Open** finds an existing one; the welcome screen also lists recent projects. - A project can be moved or renamed like any file. Open it again from its new location and the recent-projects list catches up. - Delete a project by deleting the file. There is no cloud copy to clean up. - Keep a project per engagement or per period, whichever matches how you file your working papers. A project holds as many datasets as you like. > Projects can be large once they hold big datasets and many results. Keep > them on a local drive; a project on a slow network share works but every > test will feel it. ## Bring data in ### Files **Data → Add a data file** accepts CSV, TSV and other delimited text files of any size, and Excel workbooks (`.xlsx`, `.xlsm`, `.xlsb`, `.xls`, `.ods`). DALI reads the layout itself: the delimiter, the header row, and the type of each column (text, number, date, yes/no). Every row is kept. If a column mixes formats (a date column with a few values written differently), DALI keeps that one column as text rather than dropping rows, and says so in the notes shown after the import. A file that is not in Unicode is read as Latin-1, so accented names survive. ### Excel workbooks A workbook is read one sheet at a time. If it has several sheets, DALI asks which one; each sheet you bring in becomes its own dataset. A title row above the real header is skipped. Columns that Excel holds as text stay text, so an identifier like `00123` keeps its leading zeros. Excel dates come in as real dates. ### The profile Every dataset has a profile: row count, and for each column its type, how many values are blank or missing, the smallest and largest value, and, for amount columns, the total. Use the totals to tie the import back to the system it came from before you test anything. The profile is on the dataset page and in the project workbook. ### Managing datasets Open a dataset from **Data** to see its columns, its first rows, and buttons to prepare it, run a test on it, export it, or remove it from the project. Removing a dataset does not remove results already produced from it. ## Databases **Databases** pulls tables or query results straight out of PeopleSoft, Infor, Oracle, SQL Server, DB2, PostgreSQL, MySQL, or anything else that has a Windows ODBC driver installed. Your IT department will usually have the driver on the machine already, or can install it; DALI lists the drivers it finds. 1. **Add a connection.** Give it a name, pick the driver or an existing DSN, and fill in the server details. DALI never stores a password: you are asked for it when you connect, and it is forgotten when DALI closes. A DSN that signs you in with Windows, or a file driver such as Text, Excel or Access, needs no password at all: leave the login blank. 2. **Test the connection.** DALI reports the database it reached. 3. **Pick a table** from the list, or **write a query**. A preview shows the first rows so you can check the columns before pulling. 4. **Pull.** Choose a dataset name and, if you like, a row cap. The extraction query is recorded with the dataset, so a reviewer can see exactly what was asked of the system and when. > If your shop uses Windows authentication or a DSN with credentials managed > by IT, choose that. It is more secure, and it is the only way a scheduled > routine can refresh the pull while you are away. Connection profiles (without passwords) are kept in your Windows profile, so you set them up once and they follow you across projects. ## Prepare Tests are only as good as the population they run on. **Prepare** builds a new dataset from an existing one; the new dataset remembers which source rows each row came from, and the step is logged like a test. ### Filter rows Keep only the rows that match your conditions. Each condition is on one column, in the language of the column's type: text can _contain_, _be exactly_, _start with_, _end with_, _be one of_ a list, or be blank; numbers can be _at least_, _more than_, _between_ and so on; dates can be _after_, _before_, _on_, _between_, or fall on a weekend or a weekday; yes/no columns can be yes or no. Several conditions combine with **all of these must be true** or **any of these can be true**. ### Add a column Add a computed column from a recipe. The recipes: - **Days between** two dates, and **age in days** from a date to today. - **Part of a date**: the year, month, day, or weekday. - **Weekend flag**: yes when the date falls on a Saturday or Sunday. - **Multiply** by a rate, and **arithmetic** between two columns. - **Round-amount flag**: yes when an amount is a suspiciously round number. - **Just-under flag**: yes when an amount sits just under a threshold you set. - **Contains**: yes when a text column contains a word or phrase. - **Cleaned text**: trimmed, single-spaced, consistent case, for matching. - **Digits only**: strip everything but the digits from a text column. - **First characters** and **last characters** of a text column, **length** of the text, and **combine** two columns into one. ### Match up two datasets Bring two datasets together on one or more key columns. Four ways: - **Bring columns from B onto every row of A**: a lookup, such as adding the vendor master's name and status to every payment. - **Only the rows that match** in both. - **Rows of A with no match in B**: payments to vendors not on the master. - **Rows of B with no match in A**: vendors on the master with no payments. Text keys are trimmed before they are compared, and you choose whether capitalisation matters. The result is a new dataset you can test or export like any other. ## Test packs A pack is the suite an experienced auditor would run on a kind of data, ready to go. There are five: **Accounts payable**, **Payroll**, **General ledger**, **Vendor master** and **Purchasing cards**. Each is a list of the ordinary tests and Prepare steps, written in terms of roles such as "the amount" or "the vendor" rather than column names. 1. Pick the pack, then the dataset to test. Some packs can also take a second dataset, such as an employee list for the vendor-versus-employee check. 2. Confirm which column plays which role. DALI guesses from the names and types; a required role must be mapped, an optional one can stay blank. 3. Set the pack's settings, such as the approval limit, how far below it counts as just under (5% unless you change it), or what counts as a round amount. 4. Read the plan. Every step says what it looks for; a step with no column for its role is skipped and says so. 5. Run. The results appear one by one, each with an Open link, and flagged rows go to the exceptions register unless you untick that. Runs made by a pack carry the pack's name in the log. **Save as a routine** turns the run into a routine you can rerun with one click or hand to the Windows scheduler, so a pack is also the quickest way to set up continuous auditing. ## Analytics: the eight tests Pick a test across the top of **Analytics**, choose the dataset, answer the questions, and click **Run**. DALI remembers which test you used last. You can also start from a dataset's page, which fills the dataset in for you. ### Find duplicates Groups rows that share the same values in the columns you pick. Text is trimmed and compared without regard to case, so "ACME Inc" and "acme inc " count as the same. Invoice number plus amount is the classic double-payment check; vendor name plus address finds the same vendor set up twice. You get every row that belongs to a duplicate set, grouped, with the full original record beside it. ### Find gaps in a sequence Looks at a numbered column and reports every break in the sequence: missing check numbers, skipped PO numbers. Prefixes and dashes are fine, so INV-001045 is read as 1045. Numbers that appear more than once are reported too. You get a list of gaps: where each starts, where it ends, and how many numbers are missing. ### Benford's Law In real financial data, more amounts start with 1 than with 9, a well-known pattern. Made-up or manipulated numbers often break it. The test compares the leading digits of your amounts with the expected pattern, digit by digit, and gives an overall verdict using the standard conformity measure (mean absolute deviation) together with a chi-square figure. First-digit testing works from a few hundred amounts; first-two-digit testing needs thousands. A non-conforming result is a reason to look closer, not a finding by itself. ### Age the items Puts every row into an age bucket from a date column and an as-of date, and totals each bucket: the same buckets an AR aging report uses, applied to any list with a date. You get every row with its age in days and its bucket, oldest first, plus a bucket-by-bucket total you can tie to the ledger. ### Total by group Groups the rows by one or more columns and shows the count, total, smallest, largest and average for each group, largest first: spend by vendor, count by department, total by account. Each group also shows its share of the grand total. ### Band the amounts Splits the amounts into bands and shows how many rows and how much value sit in each. Use it to spot a pile of payments just under an approval threshold, or to plan a sample. You get one row per band with its count, total and share of the whole. ### Compare two lists for near-matches Finds names that are probably the same even when they are not spelled the same: "Smith, John" and "John D Smith Services LLC", or "Bravo Consulting" and "Bravo Konsulting". Business suffixes, punctuation and word order are ignored. Compare a vendor list with an employee list, or a list with itself to find the same vendor entered two ways. Every pair is scored 0 to 100, best matches first, with both full records side by side so you can decide. ### Pull a sample Selects items to test. Random and systematic samples give every item an equal chance; a monetary-unit sample gives big-dollar items a bigger chance, the standard approach for testing a balance. Every sample is reproducible: the seed is recorded, so the same settings select the same items again. Each new sample starts from a freshly drawn seed, so nobody can predict its picks; keep the seed to repeat a sample. Built-in calculators size an attribute sample or a monetary-unit sample from your confidence level and tolerable rate or misstatement. You get the selected rows in full, numbered, ready to export as your testing worksheet. ## Results and the log **Results** lists every run in the project, newest first: when it ran, which test, which dataset, how many rows it produced, and a one-line summary. Runs made by a routine carry a chip with the routine's name. Open a result to see the rows, the settings that produced them, and the exact SQL. From there you can **Export to Excel**, **Export CSV**, or delete the run (the log entry goes too). The log is the audit trail of the analysis. Together with the profile's control totals, it lets a reviewer confirm what was tested, on which population, with which settings, and reproduce it. ## Exceptions register A test result is a list of rows. The register is where those rows become work: items to review, each with a decision, a name and a note. ### Getting items in - On any result page, tick rows and click **Add ticked**, or click **Add all rows** (for Benford's Law, **Add flagged digits**). Each row becomes an open item. The same row added twice is one item. - A routine adds its findings automatically: duplicates, gaps, near-matches and flagged Benford digits. The routine's report and the home page say how many are new. ### Deciding Tick items, type a note, and choose **Clear** (reviewed, nothing wrong), **Mark as exception** (confirmed, to follow up), **Resolve** (the follow-up is finished) or **Reopen**. Every decision is kept with your name and the time, and an item's history shows them all. Set your name once in **Reviewed by**; DALI remembers it on this computer. The result page has the same buttons for the rows you tick there, so a first pass can happen where you see the data. ### The same item, found again An item is identified by what the row says, not by its row number, so when a routine reruns a test on fresh data the same duplicate is the same item and keeps its decision. An item that the latest run no longer produces is shown as **no longer flagged**, usually because the data was fixed; its history stays. **Remove** is for rows flagged by mistake; to record a decision, clear them instead. ### Getting items out **Export register** writes an Excel workbook with the register, every note, and an About sheet with the counts: a working paper in its own right. The whole-project workbook under **Export** carries the same sheet, and a routine writes the register into its dated output folder alongside each run. ## Testing a sample A sample is a list of items to examine. The testing worksheet under a sample result is where the examination is recorded, item by item, and where the conclusion comes from. ### Setting it up Say what is being tested, list the attributes each item is checked for (**Approved**, **Matches PO**, **Receipt on file**), or leave attributes blank for one pass/fail per item. Choose the confidence level you planned with, and the tolerable rate (attribute samples) or tolerable misstatement (monetary-unit samples). Put your name in **Tested by** once. ### Recording Each row has a pass, fail or n/a button per attribute; an item fails when any attribute fails, and stays "to test" until every attribute has an answer. A monetary-unit sample also has an **Audited amount** for each item: leave it blank when the evidence agrees with the recorded amount, or type what it should have been. Add a note where it helps. Every entry saves at once with your name and the time. ### The evaluation - **Attribute samples**: the sample deviation rate and the upper deviation limit at your confidence level, using the same Poisson reliability factors the planning tables use. The sample supports the control when the upper limit is at or below the tolerable rate. - **Monetary-unit samples**: each misstatement is tainted (difference divided by recorded amount) and projected by the sampling interval; items at or above the interval count at face value. The upper misstatement limit is the Stringer bound: basic precision plus the projected misstatements ranked by tainting with incremental allowance. Understatements are shown separately. The sample supports the balance when the upper limit is at or below the tolerable misstatement. Items not yet tested are counted as correct for now and called out, so a half-finished sheet never reads as a clean one. ### Getting it out **Export worksheet** writes the sample with every finding, an Evaluation sheet with the figures and the conclusion, and an About sheet with the sampling settings and seed, so the sample can be regenerated. **Send failed items to the register** puts each failed item into the exceptions register as a confirmed exception, with the failed attributes in the note. ## Export - **One result** to Excel, with an "About this test" sheet carrying the settings and the SQL, or to CSV for anything too big for Excel. - **One dataset** to Excel or CSV, from its page or from **Export**. - **The whole project** as one workbook: the log, every dataset's profile, every result, and the datasets themselves up to a row cap you set, each as a named Excel Table ready for pivots and formulas. - **Power BI Desktop**: alongside the project workbook DALI writes a `.pbids` launcher. Double-click it and Power BI Desktop opens with the workbook's tables already connected. ## Schedules **Schedules** is continuous auditing: the tests you already ran, repeated automatically on fresh data. ### Routines A routine is a set of runs captured from the log. To make one: 1. Click **New routine from the log**, name it, and tick the runs to repeat, including the Prepare steps that made the datasets the tests use. 2. DALI works out which datasets the routine needs and where each came from (a file, a workbook sheet, a database query, or an earlier Prepare step), and lists anything that would stop it running unattended. 3. Choose a folder for the exceptions, then **Save**. **Run now** refreshes every source from where it came, redoes the preparation, reruns the tests, and writes each result to Excel in a dated folder under your output folder, with a `summary.txt`. The new runs appear under **Results** marked with the routine's name. ### Scheduling **Schedule** hands the routine to the Windows Task Scheduler: daily, weekly on a weekday, or monthly on a day, at a time you choose. DALI runs the routine without opening a window. Tasks live under the "UnifiedAudit DALI" folder in the Task Scheduler library, run as you, and only while you are logged on. What a scheduled run needs: - The computer on and you logged on at that time (a locked screen is fine). - The project file not open in DALI at that moment. (If it was, the run cannot start, and the home page and Schedules page say so.) - For a database source, Windows authentication or a DSN with managed credentials. DALI never stores a password, so a connection that asks for one cannot be refreshed unattended. Change or remove a schedule from the same page. Deleting a routine removes its schedule too. Results it produced stay in the log. ## Home: today at a glance Once a project has a routine, the home page opens with **Today at a glance**: - What ran since you were last here, overnight runs called out, and how many rows the tests flagged in total. For Benford's Law that means the digits that stand out; summaries such as Total by group flag nothing. - One tile per routine: its state, when it last ran, what each test flagged with an **Open** link to the result, what is due next, and **Run now** and **Open folder** buttons. - Anything that needs attention: a failed refresh, a test that could not run, a schedule Windows has switched off, or a scheduled run that was skipped because nobody was logged on. "Since you were last here" is measured from the previous time you opened the project on this computer. ## AI assistant The assistant is **off until you turn it on** under **Settings**, and while it is off DALI makes no request to any AI service. When it is on, it uses Anthropic's Claude with your own API key, which DALI keeps in the Windows Credential Manager under your account, never in a file or a project. What it does: - **Ask DALI**, at the top of Analytics: describe what you want to check, and it answers with one test and its settings. "Open this test" fills the form; you check the settings and run it yourself. - **Explain this result**, on a result page: a plain-English account of what the test did, what the numbers mean, and what to look at next. - **Draft a finding**, from ticked items in the exceptions register: a first draft under Condition, Criteria, Cause, Effect and Recommendation, with bracketed prompts where only you know the facts. What is sent: by default, column names and types, the settings of a run, its summary and statistics, and your question. **Row values are never sent** unless you turn on **Allow row values to be sent**; then "Explain" can include the first 20 rows of a result when you ask, and "Draft a finding" sends the items you tick. Every request is noted in `ai-usage.log` in DALI's settings folder with the time, the feature, the model and the token counts. Read the assistant as a knowledgeable colleague's first take. It can be wrong, it does not see your source documents, and it never runs anything: you decide what to run and what to conclude. ## Settings **Settings**, near the foot of the left menu, holds the two things that can reach outside your computer: the AI assistant and the update check. Both are off until you switch them on. ## Updates DALI does not phone home. It makes no network request of any kind unless you click **Check for updates** on the home page, or turn on **Check automatically when DALI starts**. That check reads one small version file from unifiedaudit.com, at most once a day, and sends nothing about you, your computer or your data. When a newer version exists, DALI says so and offers the download page. Every release is digitally signed by UnifiedAudit LLC. Install the new version over the old one; your projects, connections and routines are untouched. The release notes on the download page say what changed. A check made before you upgraded is set aside afterwards, unless it names a version newer than the one you now have. ## Where things live - **Projects**: `Documents\DALI Projects`, unless you chose another folder. - **Connection profiles and recent projects**: your Windows profile, under `AppData\Roaming\com.unifiedaudit.dali`. No passwords are kept there. - **Routine output**: the folder you chose for each routine, one dated subfolder per run. - **The scheduled-run log**: `routine-runs.log` in the same AppData folder, one line per run with its outcome. - **Scheduled tasks**: Task Scheduler, folder "UnifiedAudit DALI". ## When something goes wrong **Windows would not install it, or warned about the publisher.** DALI is signed by UnifiedAudit LLC. If SmartScreen still shows a warning for a new download, choose **More info**, check the publisher reads UnifiedAudit LLC, and run. Installation is per user and needs no administrator rights. **DALI does not start and mentions a missing DLL.** The Microsoft Visual C++ runtime is not installed on that machine. It is a free download from Microsoft ("Visual C++ Redistributable, x64") and is usually already present. **A file will not import.** Look at the notes DALI shows: a column with mixed formats is kept as text, and a ragged file (rows with too few or too many fields) is read leniently with a note saying how many rows were affected. If the file is not a delimited text file at all (a PDF, a fixed-width report), export it again from the source system as CSV or Excel. **The database driver is missing.** The Databases page lists the ODBC drivers installed on this computer. Ask IT for the driver for your database (Oracle, IBM DB2, SQL Server and the rest publish 64-bit ODBC drivers), then add the connection again. **A scheduled run did not happen.** Check, in order: was the computer on and were you logged on; was the project open in DALI at that time; has the source file moved; does the database connection need a typed password. The home page reports what the Task Scheduler says, `routine-runs.log` has one line per attempt, and `summary.txt` in the run's folder shows which step stopped. **A test ran but the result looks wrong.** Open the result and read the settings and the SQL: the columns picked, the as-of date, the threshold. Most surprises are a column of the wrong type (an amount read as text because of a stray character) and are visible in the dataset's profile. ## Glossary - **Dataset**: a table in the project, brought in from a file or a database or made by a Prepare step. - **Run**: one execution of a test or a Prepare step, numbered in the log. - **Result**: the rows a run produced, kept in the project. - **Log**: the list of every run with its settings and SQL. - **Routine**: a saved set of runs that can be repeated on fresh data. - **Control total**: a figure (row count, sum of an amount) used to tie an import back to the system it came from. - **Profile**: the per-column summary of a dataset, including control totals. - **MAD**: mean absolute deviation, the standard measure of how far a set of amounts departs from Benford's Law. - **Monetary-unit sample**: a sample in which each dollar, rather than each item, has an equal chance of selection, so large items are more likely to be chosen. - **ODBC**: the Windows standard through which programs talk to databases; a driver per database product, and optionally a DSN (a saved connection set up in Windows).