## TL;DR

dbt found two macros named cents_to_dollars, usually your local copy plus one from a package such as dbt_utils, or the same file in two macro paths. Keep one: delete or rename the local copy, or namespace the call. Calls without a package prefix resolve ambiguously, so removing the duplicate restores parsing.

```text
dbt found two macros with the same name 'cents_to_dollars'
```

## Use this when

- dbt parse or run fails saying dbt found two macros with the same name cents_to_dollars
- you recently added a local cents_to_dollars macro or installed a package that provides one
- the macro exists both under macros/ and inside dbt_packages/

## Not for this skill when

- you intentionally override a package macro, use the documented dispatch or rename pattern instead of a bare duplicate
- the duplicate name is a model or test, not a macro
- only one definition exists and the error names a different macro

## Steps

1. Search the project and installed packages for the definition: grep for macro cents_to_dollars across macros/ and dbt_packages/. List every file that defines it.
   Verify: you have the full list of defining files, usually two.

2. Decide which implementation callers should use by reading both bodies; they often differ in rounding or null handling. Check call sites by grepping for cents_to_dollars( across models/.
   Verify: you know which version the models were written against.

3. Remove the duplicate: delete the local file if the package version is correct, or rename the local macro to a project-specific name such as cents_to_dollars_local and update its call sites. Run dbt deps again if you changed packages.yml.
   Verify: only one definition of the name remains.

4. Run dbt parse, then dbt compile on two models that call the macro and diff the compiled SQL against expectations for rounding and nulls.
   Verify: parse succeeds and compiled SQL matches the chosen implementation.

## Variant phrasings

### duplicate appears after dbt deps
A new package version added the same macro. Pin the package version in packages.yml or drop your local copy in the same change.

### duplicate within your own macros folder
A copied file left in a backup subfolder still counts if the folder is under macro-paths. Move backups outside the project paths.

Compatibility: dbt-core 1.x macro resolution across project macro-paths and dbt_packages. Package macros can be called with a package prefix to disambiguate.

## Why it happens

Macro names live in a flat namespace per project unless called with a package prefix. When two definitions share a name, dbt cannot know which one a bare call means, so it errors at parse time rather than silently picking one. Local copies of utility macros are the usual second definition.

## Edge cases / pitfalls

- Deleting the file is not enough if a stale copy remains in target/ or a copied project folder; search the whole repo.
- Renaming the macro without updating callers converts this error into a macro not found error.
- Behavior differences between the two bodies can change money columns; verify rounding on a known value after deduping.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aa6JPPwncNVhIzx5mDomuw